Re: [PATCH] schemas: Add vim modeline

["Daniel P. Berrangé" <berrange@redhat.com>]

On Fri, Jul 31, 2020 at 02:55:34PM +0200, Markus Armbruster wrote:
> Daniel P. Berrangé <berrange@redhat.com> writes:

> >> Some of the criticism there doesn't matter for our use case.
> >
> > Yeah, what matters is whether it can do the job we need in a way that is
> > better than what we have today, and whether there are any further options
> > to consider that might be viable alternatives.
> 
> Would it improve things enough to be worth the switching pain?

The short answer is that I don't think that question matters. We should
do the conversion regardless, as our JSON-but-not file format has no
compelling reason to exist as a thing when there's a variety of standard
file formats that could do the job. I'd explicitly ignore the sunk costs
and minor amount of work to convert to a new format.

The long answer is that as a general philosophy I'm in favour of agressively
eliminating anything that is custom to a project and isn't offering an
compelling benefit over a functionally equivalent, commonly used / standard
solution.

Any time a project re-invents the wheel, that is one more piece of custom
knowledge a contributor has to learn. Each one may seem insignificant on
its own, but cummulatively they result in death by a 1000 cuts. This makes
a project increasingly less attractive to contribute to over the long term.

Measuring the long term benefit of the change is generally quite difficult,
because while you can see what impact a change will have today on current
code, it is hard to usefully evaluate future benefits as you're trying to
imagine the impact on things that don't even exist.

Overall my POV is not to think too hard about measuring improvements, and
discard any concern about sunk costs. Instead have a general presumption
in favour of eliminating any examples of wheel re-invention in a project.
Even if regular contributors don't want to spend time on such work, this
kind of thing is pretty amenable to new contributors looking for tasks to
start their involvement.

The QAPI JSON-but-not file format is a case where I think we should just
adopt a standard file format no matter what. A conversion will have some
short term work, but this is really simple data to deal with and the code
involved is nicely self contained. Again I'm not saying QAPI maintainers
must do it, just put the idea out there as a piece of work that would
be welcomed if someone is interested in working ont.

Another example would be elimination of anything in QEMU code that is
duplicating functionality in GLib, even if there zero functional
difference between the two impls.

Another example would be adopting a standard code style and using a
tool like clang-format to enforce this for entire of existing code
base and future contributions and throwing away our checkpatch.pl
which nearly everyone is scared of touching as it is Perl code.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|