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

["Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>]

> ... 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

Does anyone in the Xen/ia64 community have an employee or
contractor located in Cambridge that could assist with
adding Xen/ia64 automated test support to the Cambridge
automated regression test suite?  I think this would be
an important contribution towards the long term stability
of Xen/ia64... and it seems unlikely that it will happen
anytime soon without help from the Xen/ia64 community.

Thanks,
Dan

> -----Original Message-----
> From: Ian Pratt [mailto:m+Ian.Pratt@xxxxxxxxxxxx] 
> Sent: Thursday, February 09, 2006 5:34 PM
> To: Magenheimer, Dan (HP Labs Fort Collins); 
> xen-devel@xxxxxxxxxxxxxxxxxxx
> Cc: ian.pratt@xxxxxxxxxxxx
> Subject: RE: [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-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-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel