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

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 19:02:27 -0800
Delivery-date: Fri, 27 Jan 2006 03:11:39 +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/fAAAyI1IAAJNjNQAACcXMA=
Thread-topic: [Xen-devel] RE: New Release Process
Ian Pratt wrote:
>> 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
> 
> Normally I'd totally agree, but these changes are actually quite
> orthogonal: hvm basically touches just xen, and the linux tree upgrade
> is self contained. Those doing hvm testing could carry on using a
> 2.6.12 dom0 kernel from this week, just to keep things isolated.

The hvm stuff heavily depends on dom0, tools, and xen. If the developers
don't know if the hvm is broken or other things are broken, they won't
move to the new tree until the things get stable, i.e. fewer people will
be working on the unstable tree. Given the number (easily >20) of people
working on hvm (not just Intel), to accelerate the process I think a day
of checkpointing would be worth it (there can be potential merge errors,
too). That way we can get more people debugging problems with the new
linux side in the unstable because those will be the blocking issues for
them eventually.

> 
> Whether we should go straight to 2.6.16-rc1, or whether we should go
> via 
> 2.6.12-subarchxen and 2.6.15 is less clear. 2.6.12-subarch and 2.6.15
> both seem pretty stable on 32b, but x86_64 needs more testing. I'd
> certainly be inclined to check-in each of those trees, even if we
> didn't let them mature at the tip for very long. People could then at
> least roll-back for 'binary chop' purposes.
> 
> views?

One way would be to have multiple linux trees in the unstable, and make
it possible to choose which linux tree to build (at make world time, for
example). If one is more stable than the other one, we can debug more
efficiently because we have more data points. 

I think having both 2.6.15 and 2.6.16-rc1 trees is the shortest way to
get 2.6.16 ; presumably 2.6.15 is much closer to 2.6.16 (than
2.6.12-subarch). As we get 2.6.15 stable, we would duplicate the fixes
to 2.6.16-rcX. 

> 
> Ian


Jun
---
Intel Open Source Technology Center

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