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

RE: [Xen-devel] 3.0.x release mechanism clarification please?

  • To: "Magenheimer, Dan \(HP Labs Fort Collins\)" <dan.magenheimer@xxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
  • Date: Fri, 10 Feb 2006 00:33:55 -0000
  • Delivery-date: Fri, 10 Feb 2006 00:45:17 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcYtup0x8qFe6na9R6ay9CtXTzsQ9gAAmJkA
  • Thread-topic: [Xen-devel] 3.0.x release mechanism clarification please?

> Could someone please explain the "release" mechanism -- both 
> current and planned if they are different -- for the various 
> 3.0.x releases?
> In particular:
> - Is 3.0.x a frozen released set of bits -- like Linux which
>   releases tarballs that never change (e.g. linux-2.6.15.tar.gz)
>   but may spawn sub-releases (e.g. linux- --
>   or a "living" set of bits represented only by the current tip
>   of http://tx.downloads.xensource.com/xen-3.0-testing.hg?

The intention is to backport critical fixes to form 3.0.x-y releases,
much like Linux. 

xen-3.0-testing.hg are 'living bits', at least until the following

After pulling patches into 3.0-testing, the autobuild scripts should
hopefully churn out a new set of tar balls and RPMs, though some of this
process has yet to be fully  automated (on our todo list).

> - What is the decision criteria for declaring a release?

3.0.1 was somewhat rushed as we wanted to get on and check a bunch of
stuff into -unstable so we could give SuSE a sporting chance of having
something stable based on 2.6.16 for their sles10 beta.

We ran the proto 3.0.1 tree through some fairly serious regression tests
on a whole bunch of machines and nothing untoward showed up so we called
the release. Of course, our automated tests only currently test x86
32/32p/64 xen. We should fix this and add ia64 (we now have a couple of
machines). It's on the (long) todo list.


>   In the rush to 3.0.1, some late changes broke ia64 but
>   cset 8736 was tagged as RELEASE-3.0.1.  Keir was kind enough
>   to add some csets after that which fixed ia64 but we
>   are not clear on whether these fixes are "part of 3.0.1"
>   or not.  Or whether more fixes can be added to 3.0.1 (as
>   a new regression was just found which affects VTi support).
>   Clearly if 3.0.1 is "living", it's less important, but if
>   "frozen", the 3.0.1 release will not work for ia64 and
>   we'd like to fix the process so this is less likely in
>   the future.
> Thanks,
> Dan
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel

Xen-devel mailing list



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