[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.