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

["Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>]

> 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-2.6.15.1.tar.gz) --
>   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
release.

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.

Ian

>   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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel