[Qemu-devel] Qemu stable releases

[Qemu-devel] Qemu stable releases

[Justin M. Forbes]

The stable tree for 1.0 has now been created and the mailing list
exists. I am curious as to people's thoughts on how we should proceed.
There was discussion of setting up a predictable time table for stable
releases, say monthly or bimonthly, though that seems a bit difficult
from past experience.  Typically I get a flurry of patches shortly after
a release (and they have already started for 1.0).  I have tried to get
a .1 release out in a timely manner, and then it seems patches for
stable become few and far between.  In the 0.14 and 0.15 series, not
even enough to warrant a .2 release.  Perhaps this is due to lack fixed
issues, or lack of effort to submit to stable.  What I would like to
recommend is the following:

1) On the 15th of every month, the stable queue will be evaluated for
release.
2) If enough patches exist (or critical enough patches exist), a stable
release will be cut as soon as testing/push/mirror can be done.  If
there are no patches, or not enough patches to warrant a release, they
will be held over until the next release.
3) Security fixes do not follow this schedule, and will trigger a stable
release as needed.

Questions, comments, concernes? How do people feel about this?

Justin

Re: [Qemu-devel] Qemu stable releases

[Stefan Hajnoczi]

On Mon, Dec 5, 2011 at 8:08 PM, Justin M. Forbes <jmforbes@linuxtx.org> wrote:
> The stable tree for 1.0 has now been created and the mailing list
> exists.

Where does the stable 1.0 tree live?

Stefan

Re: [Qemu-devel] Qemu stable releases

[Richard W.M. Jones]

On Mon, Dec 05, 2011 at 02:08:03PM -0600, Justin M. Forbes wrote:
> The stable tree for 1.0 has now been created and the mailing list
> exists. I am curious as to people's thoughts on how we should proceed.
> There was discussion of setting up a predictable time table for stable
> releases, say monthly or bimonthly, though that seems a bit difficult
> from past experience.  Typically I get a flurry of patches shortly after
> a release (and they have already started for 1.0).  I have tried to get
> a .1 release out in a timely manner, and then it seems patches for
> stable become few and far between.  In the 0.14 and 0.15 series, not
> even enough to warrant a .2 release.  Perhaps this is due to lack fixed
> issues, or lack of effort to submit to stable.  What I would like to
> recommend is the following:
> 
> 1) On the 15th of every month, the stable queue will be evaluated for
> release.
> 2) If enough patches exist (or critical enough patches exist), a stable
> release will be cut as soon as testing/push/mirror can be done.  If
> there are no patches, or not enough patches to warrant a release, they
> will be held over until the next release.
> 3) Security fixes do not follow this schedule, and will trigger a stable
> release as needed.
> 
> Questions, comments, concernes? How do people feel about this?

Is there a policy for what commits count as stable?

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 ..."

This is easy and has worked out well for us.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw

Re: [Qemu-devel] Qemu stable releases

[Richard W.M. Jones]

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 ..."

For completeness, here is an example stable branch containing
cherry-picked commits:

http://fedorapeople.org/git/?p=rjones/public_git/libguestfs.git;a=log;h=refs/remotes/origin/stable-1.14

Compare to the master branch to see which commits did and didn't make
it in.

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/

Re: [Qemu-devel] Qemu stable releases

[Andreas Färber]

Am 05.12.2011 21:08, schrieb Justin M. Forbes:
> Typically I get a flurry of patches shortly after
> a release (and they have already started for 1.0).  I have tried to get
> a .1 release out in a timely manner, and then it seems patches for
> stable become few and far between.  In the 0.14 and 0.15 series, not
> even enough to warrant a .2 release.  Perhaps this is due to lack fixed
> issues, or lack of effort to submit to stable.

> 3) Security fixes do not follow this schedule, and will trigger a stable
> release as needed.

I would've thought that the usb-ccid CVE alone warrants a 0.15.2 of qemu
and qemu-kvm. I am surprised nothing has happened there yet...

http://patchwork.ozlabs.org/patch/128064/

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] Qemu stable releases

[Anthony Liguori]

On 12/09/2011 06:55 AM, Andreas Färber wrote:
> Am 05.12.2011 21:08, schrieb Justin M. Forbes:
>> Typically I get a flurry of patches shortly after
>> a release (and they have already started for 1.0).  I have tried to get
>> a .1 release out in a timely manner, and then it seems patches for
>> stable become few and far between.  In the 0.14 and 0.15 series, not
>> even enough to warrant a .2 release.  Perhaps this is due to lack fixed
>> issues, or lack of effort to submit to stable.
>
>> 3) Security fixes do not follow this schedule, and will trigger a stable
>> release as needed.
>
> I would've thought that the usb-ccid CVE alone warrants a 0.15.2 of qemu
> and qemu-kvm. I am surprised nothing has happened there yet...
>
> http://patchwork.ozlabs.org/patch/128064/

We don't have a clear EOL schedule for stable releases.  Historically, stable 
releases only lasted until the next release cycle so in by that logic, 0.15 is EOL.

Obviously, part of creating a regular cadence for stable releases and getting 
more people involved is to formalize this all quite a bit more.

Regards,

Anthony Liguori

>
> Andreas
>

Re: [Qemu-devel] Qemu stable releases

[Anthony Liguori]

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?

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.

Regards,

Anthony Liguori

> For completeness, here is an example stable branch containing
> cherry-picked commits:
>
> http://fedorapeople.org/git/?p=rjones/public_git/libguestfs.git;a=log;h=refs/remotes/origin/stable-1.14
>
> Compare to the master branch to see which commits did and didn't make
> it in.
>
> Rich.
>

Re: [Qemu-devel] Qemu stable releases

[Justin M. Forbes]

On Fri, 2011-12-09 at 13:55 +0100, Andreas Färber wrote:
> Am 05.12.2011 21:08, schrieb Justin M. Forbes:
> > Typically I get a flurry of patches shortly after
> > a release (and they have already started for 1.0).  I have tried to get
> > a .1 release out in a timely manner, and then it seems patches for
> > stable become few and far between.  In the 0.14 and 0.15 series, not
> > even enough to warrant a .2 release.  Perhaps this is due to lack fixed
> > issues, or lack of effort to submit to stable.
> 
> > 3) Security fixes do not follow this schedule, and will trigger a stable
> > release as needed.
> 
> I would've thought that the usb-ccid CVE alone warrants a 0.15.2 of qemu
> and qemu-kvm. I am surprised nothing has happened there yet...
> 
> http://patchwork.ozlabs.org/patch/128064/
> 

I suppose that also brings up the question of how long a stable branch
should be supported?  Perhaps we should do stable through 2 release
cycles, so that 0.15 stable would stop when 1.1 is released?

Justin

Re: [Qemu-devel] Qemu stable releases

[Richard W.M. Jones]

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/

Re: [Qemu-devel] Qemu stable releases

[Andreas Färber]

Am 09.12.2011 14:24, schrieb Anthony Liguori:
> On 12/09/2011 06:55 AM, Andreas Färber wrote:
>> Am 05.12.2011 21:08, schrieb Justin M. Forbes:
>>> Typically I get a flurry of patches shortly after
>>> a release (and they have already started for 1.0).  I have tried to get
>>> a .1 release out in a timely manner, and then it seems patches for
>>> stable become few and far between.  In the 0.14 and 0.15 series, not
>>> even enough to warrant a .2 release.  Perhaps this is due to lack fixed
>>> issues, or lack of effort to submit to stable.
>>
>>> 3) Security fixes do not follow this schedule, and will trigger a stable
>>> release as needed.
>>
>> I would've thought that the usb-ccid CVE alone warrants a 0.15.2 of qemu
>> and qemu-kvm. I am surprised nothing has happened there yet...
>>
>> http://patchwork.ozlabs.org/patch/128064/
> 
> We don't have a clear EOL schedule for stable releases.  Historically,
> stable releases only lasted until the next release cycle so in by that
> logic, 0.15 is EOL.

Unfortunately qemu(-kvm) 1.0 came too late for SLES 11 SP2, so we're now
forced to ship 0.15.1 plus a ton of hand-picked patches.

Therefore I would appreciate finding some solution to keep 0.15 branch
usable, whatever tarballs you release on qemu.org or declare EOL.

Regards,
Andreas

> Obviously, part of creating a regular cadence for stable releases and
> getting more people involved is to formalize this all quite a bit more.
> 
> Regards,
> 
> Anthony Liguori

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg