Re: [Qemu-devel] KVM call for 2017-03-14

[Kevin Wolf]

Am 14.03.2017 um 13:20 hat Markus Armbruster geschrieben:
> Kevin Wolf <address@hidden> writes:
> 
> > Am 14.03.2017 um 10:24 hat Thomas Huth geschrieben:
> >> >   - in all areas our legacy code and back-compatibility requirements
> >> >     are threatening to choke forward progress if we don't make serious
> >> >     efforts to get on top of them
> >> 
> >> ... and don't forget all the code that is in "orphan" state since many
> >> years... it's often hard to get patches accepted that primarily touches
> >> files that nobody feels responsible for...
> >> 
> >> Maybe it's really time for a "spring-cleaning", break with some
> >> compatibility cruft and do a 3.0 release afterwards ;-)
> >
> > If we decide that the situation is bad enough to do this, I'd vote for
> > breaking not just "some" compatibility for a usual release after three
> > months, but to take more time for it, completely break with the old
> > interfaces and declare this a new QEMU that libvirt should have a
> > separate driver for. And then throw out _all_ of the interfaces that
> > don't match the design any more that we have in mind, even if this means
> > a temporary regression in features.
> >
> > This means one big cut rather than having every release just slightly
> > incompatible with the previous releases, which should actually make it
> > more managable, even though the change is more radical.
> 
> Of course, "legacy code and back-compatibility requirements" will start
> to grow back the minute we release new interfaces.  Whether a big cut is
> worthwhile depends on the seriousness of the current situation and the
> rate of regrowth.  There's hope the weeds will grow more slowly around
> well-designed new interfaces.

There is no doubt that this would happen. But we've managed to keep
compatibility more or less for 10 years, so if we extrapolate from that,
it means that in another 10 years we need another cut. Doesn't sound too
bad.

I'm not completely sure whether our situation really requires it, but
it's true that we're (or at least I am) spending a lot of time for
keeping compatibility with old interfaces that nobody really likes and
that simply don't match any more how things really work.

There are more nice-to-have things like consistently spelt option names
and monitor commands that will never be important enough to be cleaned
up on their own.

So I'm not saying that we should do this big cut, but _if_ we say that
3.0 is to be considered incompatible, then I'd go for the radical
approach rather than making things incompatible in hundreds of details,
but not really attacking the big problems that slow down development.

Kevin