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

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



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

Thanks, Jan


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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.