|   | 
      | 
  
  
      | 
      | 
  
 
     | 
    | 
  
  
     | 
    | 
  
  
    |   | 
      | 
  
  
    | 
         
xen-devel
[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?
- 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
 
 |   
 
| <Prev in Thread] | 
Current Thread | 
[Next in Thread>
 |  
- [Xen-devel] 3.0.x release mechanism clarification please?,
Magenheimer, Dan (HP Labs Fort Collins) <=
 
 
 |  
  
 | 
    | 
  
  
    |   | 
    |