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

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


  • To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
  • Date: Thu, 9 Feb 2006 12:51:35 -0800
  • Delivery-date: Thu, 09 Feb 2006 21:02:55 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcYtup0x8qFe6na9R6ay9CtXTzsQ9g==
  • Thread-topic: 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@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®.