Xen devel - Feb 2006 - 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-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?
- What is the decision criteria for declaring a release?
  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@lists.xensource.com
http://lists.xensource.com/xen-devel

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