All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: Thomas Huth <thuth@redhat.com>,
	Peter Maydell <peter.maydell@linaro.org>,
	QEMU Developer <qemu-devel@nongnu.org>,
	KVM devel mailing list <kvm@vger.kernel.org>,
	Juan Quintela <quintela@redhat.com>
Subject: Re: [Qemu-devel] KVM call for 2017-03-14
Date: Tue, 14 Mar 2017 13:20:26 +0100	[thread overview]
Message-ID: <87y3w89hit.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <20170314101351.GC3952@noname.str.redhat.com> (Kevin Wolf's message of "Tue, 14 Mar 2017 11:13:51 +0100")

Kevin Wolf <kwolf@redhat.com> 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.

  reply	other threads:[~2017-03-14 12:20 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-12 20:45 KVM call for 2017-03-14 Juan Quintela
2017-03-12 20:45 ` [Qemu-devel] " Juan Quintela
2017-03-13 10:02 ` Peter Maydell
2017-03-13 12:50   ` Alex Bennée
2017-03-13 14:12   ` Juan Quintela
2017-03-13 14:12     ` [Qemu-devel] " Juan Quintela
2017-03-13 14:17     ` Peter Maydell
2017-03-13 14:17       ` [Qemu-devel] " Peter Maydell
2017-03-14  8:03     ` Stefan Hajnoczi
2017-03-14  8:13   ` Stefan Hajnoczi
2017-03-14  8:37     ` Peter Maydell
2017-03-14  8:59       ` Juan Quintela
2017-03-14  8:59         ` [Qemu-devel] " Juan Quintela
2017-03-14 10:56         ` Peter Maydell
2017-03-14 10:56           ` [Qemu-devel] " Peter Maydell
2017-03-15  8:39           ` Christian Borntraeger
2017-03-15  8:39             ` [Qemu-devel] " Christian Borntraeger
2017-03-15 10:29           ` Greg Kurz
2017-03-15 11:25             ` Laurent Vivier
2017-03-15 11:25               ` Laurent Vivier
2017-03-15 16:35               ` Greg Kurz
2017-03-14 16:01         ` Dr. David Alan Gilbert
2017-03-14 16:20           ` Daniel P. Berrange
2017-03-14 16:54             ` Obsolete QEMU host environments (was: Re: KVM call for 2017-03-14) Thomas Huth
2017-03-14 16:54               ` [Qemu-devel] " Thomas Huth
2017-03-14 17:07               ` Peter Maydell
2017-03-14 17:07                 ` [Qemu-devel] " Peter Maydell
2017-03-14 21:09                 ` Obsolete QEMU host environments Richard Henderson
2017-03-14 21:09                   ` [Qemu-devel] " Richard Henderson
2017-03-15  9:40                   ` Daniel P. Berrange
2017-03-15  9:40                     ` [Qemu-devel] " Daniel P. Berrange
2017-03-15 10:02                     ` Thomas Huth
2017-03-15 10:02                       ` [Qemu-devel] " Thomas Huth
2017-03-15 15:46                   ` Aurelien Jarno
2017-03-15 15:46                     ` [Qemu-devel] " Aurelien Jarno
2017-03-14 17:14             ` [Qemu-devel] KVM call for 2017-03-14 Paolo Bonzini
2017-03-14 17:18           ` Peter Maydell
2017-03-14 17:29             ` Dr. David Alan Gilbert
2017-03-15  8:30               ` Gerd Hoffmann
2017-03-14  9:33       ` Markus Armbruster
2017-03-14  8:53     ` Juan Quintela
2017-03-14  8:53       ` [Qemu-devel] " Juan Quintela
2017-03-14 10:39     ` Peter Maydell
2017-03-14 10:44       ` Paolo Bonzini
2017-03-14  9:24   ` Thomas Huth
2017-03-14 10:13     ` Kevin Wolf
2017-03-14 12:20       ` Markus Armbruster [this message]
2017-03-14 12:35         ` Kevin Wolf
2017-03-14 10:32     ` Peter Maydell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87y3w89hit.fsf@dusky.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=kwolf@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.