WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] RE: New Release Process

To: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>, "Anthony Liguori" <aliguori@xxxxxxxxxx>, "xen-devel" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] RE: New Release Process
From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
Date: Thu, 26 Jan 2006 18:20:48 -0000
Delivery-date: Thu, 26 Jan 2006 18:29:47 +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/fA=
Thread-topic: New Release Process
> > 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.

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.

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 ?

Any reason not to call 3.0.1 now? There are a load of bug fixes and
improvements over 3.0.0.

Ian



  








_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel