Re: [Xen-devel] Next 4.6.x stable release, numbering, qemu-tag

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Wed, Jun 15, 2016 at 03:56:20AM -0600, Jan Beulich wrote:
> >>> On 15.06.16 at 11:03, <wei.liu2@xxxxxxxxxx> wrote:
> > On Wed, Jun 15, 2016 at 01:38:41AM -0600, Jan Beulich wrote:
> >> >>> On 14.06.16 at 19:57, <ian.jackson@xxxxxxxxxxxxx> wrote:
> >> > We still have an unanswered question about the forthcoming 4.6.x
> >> > stable release.  To summarise:
> >> > 
> >> > After tagging qemu-xen-4.6.2, a build issue was discovered: qemu-xen
> >> > wanted a new patch to fix the build on recent Ubuntu.  We decided to
> >> > include this patch in the forthcoming stable point release of Xen 4.6.
> >> > So we will need to retag qemu-xen as part of the release process.
> >> > 
> >> > In my view the correct thing to do in this situation is to skip the
> >> > version number.  This is also, I think, quite conventional in other
> >> > projects, if new release-critical changes are discovered during the
> >> > release preparation.
> >> > 
> >> > I think it would be quite wrong to "release 4.6.2 with qemu-xen
> >> > c5fbb56ac828".  Indeed, I think it is now impossible to do a correct
> >> > release of 4.6.2 containing qemu-xen c5fbb56ac828, because making a
> >> > release of Xen (including a stable point release) involves making a
> >> > corresponding tag in the qemu trees.
> >> > 
> >> > Those corresponding tags are not just a technical link to Config.mk,
> >> > used by build automation.  They also have an independent existence.
> >> > They are PGP signed.  They can be verified outside the context of
> >> > xen.git's Config.mk.  They are looked at by humans.  git-describe uses
> >> > them.  Xen-specific automation might pick them up, knowing our tag
> >> > naming conventions.
> >> > 
> >> > We should therefore discard the version number 4.6.2 and proceed with
> >> > the forthcoming point release as 4.6.3.  Integers are plentiful and it
> >> > does not matter if we waste one, particularly in the point release
> >> > number.  We can mention briefly somewhere (release notes maybe) that
> >> > we skipped 4.6.2 because we discovered a patch we wanted to include,
> >> > while we were in the process of preparing the release.
> >> > 
> >> > We have spoken about this informally and it seems that Jan, the
> >> > primary stable tree maintainer, does not agree (or at least, has not
> >> > yet been convinced).
> >> > 
> >> > This may seem like a bikeshed issue to some.  But, I'm afraid that I
> >> > am very reluctant to do as Jan proposes, and proceed with a 4.6.2
> >> > release referring to a qemu tag such as qemu-xen-4.6.2.1 or 4.6.2b or
> >> > something.  Before doing that I would feel the need to escalate this
> >> > question to the Xen Project Committers (CC'd).
> >> > 
> >> > And, we ought not to let this issue delay the actual point release and
> >> > it is close to being on the critical path.  A decision is needed.
> >> 
> >> As said on IRC this morning, while I continue to by unconvinced of the
> >> arguments, being the only one wanting to stick with 4.6.2 I'm not going
> >> to argue any further on this - be it 4.6.3 then. The only thing I would
> >> really like to ask is that this time (as should have happened in the first
> >> place), before tagging respective trees, everyone please make sure
> >> everything intended to be in the tree they're responsible for indeed is
> >> there. I really want to be able to rely on everybody having their trees
> >> (or parts thereof) under control.
> >> 
> >> (I don't, btw, think that mini-os strictly needs re-tagging. We've
> >> shipped 4.6.1 without a new tag too, since there were no changes.
> >> But of course if a new tag is going to be made, please make sure
> >> you let me know of its existence, so my final Config.mk adjustment
> >> can be done appropriately.)
> >> 
> > 
> > I would like to tag 4.6.3 to avoid causing confusion.
> > 
> > Let me know when the decision about version number is final.
> 
> The decision to go with 4.6.3 is final afaict, but what I'm unclear
> about is when things are actually going to be ready in the other
> trees (and hence how high the risk is that some mini-os fix shows
> up which then also absolutely want in the upcoming stable
> release).
> 

I can tag the tree till the last minute. The possibility that some
critical patch shows up is rather low -- a lot lower than the other
trees.

Wei.

> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel