This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


RE: [Xen-devel] RE: New Release Process

To: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>, "Anthony Liguori" <aliguori@xxxxxxxxxx>, "xen-devel" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] RE: New Release Process
From: "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>
Date: Thu, 26 Jan 2006 11:42:48 -0800
Delivery-date: Thu, 26 Jan 2006 19:51:50 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcYdSsMHOE5/IVW3RVWzkvnj8ZZ9KAD6pUywAFpT/fAAAyI1IA==
Thread-topic: [Xen-devel] RE: New Release Process
Ian Pratt wrote:
>>> I was hoping you could clarify what the decisions were for the new
>>> release process that you proposed at the Winter XenSummit.
>> We decided to try to aim for ~6 week intervals for 3.0.x
>> releases, stablizing the tree in -unstable then doing the
>> release and sweeping the code into 3.0-testing. We'll then
>> try and backport critical fixes from -unstable into
>> 3.0-testing and spin new 3.0.x-y build numbers as required.
>> Any similarity to the Linux process is purely intentional :)
> Here's my thoughts on how we should kick-off with the new release
> process:
> It's been over 6 weeks since the 3.0.0 release, and the -unstable tree
> is actually looking pretty good right now -- two of the bugs I
> mentioned yesterday are now fixed.
> My current inclination is to call a 3.0.1 release Friday/Saturday and
> sweep the tree into -testing. Monday morning we'd then incorporate hvm
> and the 2.6.15 tree and work flat out to get that fully tested and
> stabilized ASAP, so SuSE can pick it up for SLES10.

I think it would be better if we incorporate them one by one, not them
together on the _same_ day (I doubt you are doing that, though), because
we can debug effectively focusing on fewer problems. For example,
1. hvm, 2. sanity testing (a day or two), 3. 2.6.15 or 2.6.16-rcX

This way we can get more hvm people focusing on 2.6.15 or 2.6.16-rcX.

> SuSE have said they are actually going to base their release off
> 2.6.16, even though we're still likely to be on 2.6.16-rcX by their
> freeze date. One thing we could do to help them is to break with
> tradition and to check the 2.6.16-rcX into the tree rather than the
> most recent stable release, 2.6.15. This would help get 2.6.16
> stabilized quicker, which would certainly help them. 2.6.16 is
> already at rc1, which means that many of the 'rough edges' should
> have been found, so I doubt we'll be hurting ourselves too much. This
> is -unstable, after all. 

I like the idea of prefetching. 

> What do other developers feel about trying to help SuSE out like this?
> No doubt we might have to end up doing something similar for RH come
> the RHEL5 freeze date. My feeling is that its in the xen community's
> interest to have the best possible vendor releases, as the users
> always end up coming to our mailing lists to complain :)
> What do you think? Should we stick with 2.6.15 or go to 2.6.16-rc1 ?

Having the best possible vendor releases will definitely make our life
easier. I think we should go with 2.6.16-rc1. 

> Any reason not to call 3.0.1 now? There are a load of bug fixes and
> improvements over 3.0.0.
> Ian
I think it's a good idea to release 3.0.1 at this point. 

Intel Open Source Technology Center

Xen-devel mailing list