From: "Richard W.M. Jones" <rjones@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: "Justin M. Forbes" <jmforbes@linuxtx.org>,
qemu-devel@nongnu.org, qemu-stable@nongnu.org
Subject: Re: [Qemu-devel] Qemu stable releases
Date: Fri, 9 Dec 2011 13:47:10 +0000 [thread overview]
Message-ID: <20111209134710.GD2520@amd.home.annexia.org> (raw)
In-Reply-To: <4EE20C53.8020807@codemonkey.ws>
On Fri, Dec 09, 2011 at 07:25:39AM -0600, Anthony Liguori wrote:
> On 12/09/2011 06:01 AM, Richard W.M. Jones wrote:
> >On Fri, Dec 09, 2011 at 10:39:37AM +0000, Richard W.M. Jones wrote:
> >>FWIW in libguestfs we have such a policy. Every few weeks I evaluate
> >>_all_ commits along the development branch and cherry pick those that
> >>meet this policy back to the stable branch, followed by making a new
> >>stable release. Here is the policy:
> >>
> >>http://libguestfs.org/guestfs.3.html#libguestfs_version_numbers
> >> from "Our criteria for backporting changes are ..."
>
> Out of curiosity, what's the commit rate for libguestfs and what's
> the release schedule?
A lot less than qemu. I can't update my qemu.git at the moment but
there are 810 commits in libguestfs since 2010-12-31, and maybe 50x as
many in qemu over the same period.
Release schedule is not fixed, but it seems to average to a new stable
branch every 3-4 months.
> I tried this years ago with QEMU and while it resulted in a very
> active stable branch, it was a huge amount of work, particularly as
> we got about half way through the next development cycle.
I generally don't backport fixes if the cherry picking involves
complicated changes, because that's against the policy that fixes in
the stable branch need to be well-tested and uncontroversial. A
massive cherry pick rewrite is by definition not a well-tested change.
Splitting development commits helps: eg. if new features are split
into non-functional code motion commits + new feature commits. We
tend to backport code motion changes, which helps to make cherry
picking bug fixes simpler because the code in both branches stays
similar.
Anyhow, there you go, it may not work for qemu.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
next prev parent reply other threads:[~2011-12-09 13:47 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-05 20:08 [Qemu-devel] Qemu stable releases Justin M. Forbes
2011-12-06 9:27 ` Stefan Hajnoczi
2011-12-09 10:39 ` Richard W.M. Jones
2011-12-09 12:01 ` Richard W.M. Jones
2011-12-09 13:25 ` Anthony Liguori
2011-12-09 13:47 ` Richard W.M. Jones [this message]
2011-12-09 12:55 ` Andreas Färber
2011-12-09 13:24 ` Anthony Liguori
2011-12-09 13:50 ` Andreas Färber
2011-12-09 13:28 ` Justin M. Forbes
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=20111209134710.GD2520@amd.home.annexia.org \
--to=rjones@redhat.com \
--cc=anthony@codemonkey.ws \
--cc=jmforbes@linuxtx.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-stable@nongnu.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).