Next 4.6.x stable release, numbering, qemu-tag

Next 4.6.x stable release, numbering, qemu-tag

[Ian Jackson]

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.

Thanks for your attention.

Ian.

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

Re: Next 4.6.x stable release, numbering, qemu-tag

[Konrad Rzeszutek Wilk]

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

My personal preferred color is 4.6.2.1 (and I believe we did a similar
release in the past: RELEASE-4.1.6.1)

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

Re: Next 4.6.x stable release, numbering, qemu-tag

[George Dunlap]

On 14/06/16 20:27, Konrad Rzeszutek Wilk wrote:
>> 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.
> 
> My personal preferred color is 4.6.2.1 (and I believe we did a similar
> release in the past: RELEASE-4.1.6.1)

I thought we had a discussion about this before and determined that this
would be confusing.  My understanding was that at some point we agreed
that we'd only go with three levels, and to just "burn" a point number
if a situation like 4.1.6.1 ever came up again.  There's no reason to go
back and revisit that decision.

And Jan's point (as I understand it) is that the Xen tree has not been
tagged yet, and so the Xen release number shouldn't be restricted by the
fact that the corresponding qemu *has* been tagged.  So I suspect he'd
object to 4.6.2.1 for the same reason he objects to 4.6.3.

 -George

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

Re: Next 4.6.x stable release, numbering, qemu-tag

[Jan Beulich]

>>> On 15.06.16 at 10:57, <george.dunlap@citrix.com> wrote:
> On 14/06/16 20:27, Konrad Rzeszutek Wilk wrote:
>>> 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.
>> 
>> My personal preferred color is 4.6.2.1 (and I believe we did a similar
>> release in the past: RELEASE-4.1.6.1)
> 
> I thought we had a discussion about this before and determined that this
> would be confusing.  My understanding was that at some point we agreed
> that we'd only go with three levels, and to just "burn" a point number
> if a situation like 4.1.6.1 ever came up again.  There's no reason to go
> back and revisit that decision.
> 
> And Jan's point (as I understand it) is that the Xen tree has not been
> tagged yet, and so the Xen release number shouldn't be restricted by the
> fact that the corresponding qemu *has* been tagged.  So I suspect he'd
> object to 4.6.2.1 for the same reason he objects to 4.6.3.

Indeed. And if I have to pick between the two, I'd choose the latter.

Jan


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

Re: Next 4.6.x stable release, numbering, qemu-tag

[Jan Beulich]

>>> On 14.06.16 at 19:57, <ian.jackson@eu.citrix.com> 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@lists.xen.org
http://lists.xen.org/xen-devel

Re: Next 4.6.x stable release, numbering, qemu-tag

[Wei Liu]

On Wed, Jun 15, 2016 at 01:38:41AM -0600, Jan Beulich wrote:
> >>> On 14.06.16 at 19:57, <ian.jackson@eu.citrix.com> 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.

Wei.

> Thanks, Jan
> 

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

Re: Next 4.6.x stable release, numbering, qemu-tag

[Jan Beulich]

>>> On 15.06.16 at 11:03, <wei.liu2@citrix.com> wrote:
> On Wed, Jun 15, 2016 at 01:38:41AM -0600, Jan Beulich wrote:
>> >>> On 14.06.16 at 19:57, <ian.jackson@eu.citrix.com> 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).

Jan


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

Re: Next 4.6.x stable release, numbering, qemu-tag

[Wei Liu]

On Wed, Jun 15, 2016 at 03:56:20AM -0600, Jan Beulich wrote:
> >>> On 15.06.16 at 11:03, <wei.liu2@citrix.com> wrote:
> > On Wed, Jun 15, 2016 at 01:38:41AM -0600, Jan Beulich wrote:
> >> >>> On 14.06.16 at 19:57, <ian.jackson@eu.citrix.com> 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@lists.xen.org
http://lists.xen.org/xen-devel

Re: Next 4.6.x stable release, numbering, qemu-tag

[George Dunlap]

On 15/06/16 08:38, Jan Beulich wrote:

> 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 think this is an unreasonable expectation -- how is someone supposed
to know whether a new critical issue is going to be reported seconds
after they sign and push the tag?  It amounts to saying, "Please make
sure there are no bugs in your tree."

The version of qemu-xen that was tagged with 4.6 had been through
several rounds of RCs, months of osstesting, and even through a slew of
builds on Travis (which does build Ubuntu, but apparently just not the
bleeding-edge version).  I only happened to notice it as I was trying to
get patches for raisin for 4.7.

I am going to try to get build tests for a wide range of distros on a
regular basis, which will close this particular kind of bug.  But there
are innumerable other types of bug which still won't be caught; that's
just a fact of software development.

 -George

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

Re: Next 4.6.x stable release, numbering, qemu-tag

[Jan Beulich]

>>> On 15.06.16 at 11:35, <george.dunlap@citrix.com> wrote:
> On 15/06/16 08:38, Jan Beulich wrote:
> 
>> 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 think this is an unreasonable expectation -- how is someone supposed
> to know whether a new critical issue is going to be reported seconds
> after they sign and push the tag?  It amounts to saying, "Please make
> sure there are no bugs in your tree."

I certainly didn't mean that, and I think it is reasonably clear even
without me having said so explicitly that my expectation only applies
to already known items. After all (aiui) what we're talking about here
are not issues that showed up in the last minute, but just fell between
the cracks.

> The version of qemu-xen that was tagged with 4.6 had been through
> several rounds of RCs, months of osstesting, and even through a slew of
> builds on Travis (which does build Ubuntu, but apparently just not the
> bleeding-edge version).  I only happened to notice it as I was trying to
> get patches for raisin for 4.7.

The mere fact that 4.6.0 and 4.6.1 exhibited the same issue (and,
from what you're saying now, which is different from what I've
understood before, already did when they were cut) would make
dealing with the issue a non-release-critical one for my taste. IOW,
if a new version of Ubuntu showed up after 4.6.1, then fixing the
issue in 4.6.2 (now 4.6.3) would indeed be rather desirable. If,
however, that release was around already at the time 4.6.1 got
cut, then I don't see why this is so urgent a problem to address.
In the end we simply can't defer releases indefinitely just because
new issues keep showing up (or perhaps I should say "shouldn't",
because of course we can if we wanted to).

Jan


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

Re: Next 4.6.x stable release, numbering, qemu-tag

[George Dunlap]

On 15/06/16 11:04, Jan Beulich wrote:
>>>> On 15.06.16 at 11:35, <george.dunlap@citrix.com> wrote:
>> On 15/06/16 08:38, Jan Beulich wrote:
>>
>>> 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 think this is an unreasonable expectation -- how is someone supposed
>> to know whether a new critical issue is going to be reported seconds
>> after they sign and push the tag?  It amounts to saying, "Please make
>> sure there are no bugs in your tree."
> 
> I certainly didn't mean that, and I think it is reasonably clear even
> without me having said so explicitly that my expectation only applies
> to already known items. After all (aiui) what we're talking about here
> are not issues that showed up in the last minute, but just fell between
> the cracks.
> 
>> The version of qemu-xen that was tagged with 4.6 had been through
>> several rounds of RCs, months of osstesting, and even through a slew of
>> builds on Travis (which does build Ubuntu, but apparently just not the
>> bleeding-edge version).  I only happened to notice it as I was trying to
>> get patches for raisin for 4.7.
> 
> The mere fact that 4.6.0 and 4.6.1 exhibited the same issue (and,
> from what you're saying now, which is different from what I've
> understood before, already did when they were cut) would make
> dealing with the issue a non-release-critical one for my taste. IOW,
> if a new version of Ubuntu showed up after 4.6.1, then fixing the
> issue in 4.6.2 (now 4.6.3) would indeed be rather desirable. If,
> however, that release was around already at the time 4.6.1 got
> cut, then I don't see why this is so urgent a problem to address.

And this is exactly what happened -- the version of Ubuntu which breaks
is 16.04, which (as the name indicates) came out in April 2016 -- two
months after 4.6.1. :-)

 -George

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

Re: Next 4.6.x stable release, numbering, qemu-tag

[Jan Beulich]

>>> On 15.06.16 at 12:13, <george.dunlap@citrix.com> wrote:
> On 15/06/16 11:04, Jan Beulich wrote:
>>>>> On 15.06.16 at 11:35, <george.dunlap@citrix.com> wrote:
>>> The version of qemu-xen that was tagged with 4.6 had been through
>>> several rounds of RCs, months of osstesting, and even through a slew of
>>> builds on Travis (which does build Ubuntu, but apparently just not the
>>> bleeding-edge version).  I only happened to notice it as I was trying to
>>> get patches for raisin for 4.7.
>> 
>> The mere fact that 4.6.0 and 4.6.1 exhibited the same issue (and,
>> from what you're saying now, which is different from what I've
>> understood before, already did when they were cut) would make
>> dealing with the issue a non-release-critical one for my taste. IOW,
>> if a new version of Ubuntu showed up after 4.6.1, then fixing the
>> issue in 4.6.2 (now 4.6.3) would indeed be rather desirable. If,
>> however, that release was around already at the time 4.6.1 got
>> cut, then I don't see why this is so urgent a problem to address.
> 
> And this is exactly what happened -- the version of Ubuntu which breaks
> is 16.04, which (as the name indicates) came out in April 2016 -- two
> months after 4.6.1. :-)

In which case I don't really follow what you tried to point out with
the first sentence of your earlier reply still visible above.

Jan


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

Re: Next 4.6.x stable release, numbering, qemu-tag

[George Dunlap]

On 15/06/16 11:25, Jan Beulich wrote:
>>>> On 15.06.16 at 12:13, <george.dunlap@citrix.com> wrote:
>> On 15/06/16 11:04, Jan Beulich wrote:
>>>>>> On 15.06.16 at 11:35, <george.dunlap@citrix.com> wrote:
>>>> The version of qemu-xen that was tagged with 4.6 had been through
>>>> several rounds of RCs, months of osstesting, and even through a slew of
>>>> builds on Travis (which does build Ubuntu, but apparently just not the
>>>> bleeding-edge version).  I only happened to notice it as I was trying to
>>>> get patches for raisin for 4.7.
>>>
>>> The mere fact that 4.6.0 and 4.6.1 exhibited the same issue (and,
>>> from what you're saying now, which is different from what I've
>>> understood before, already did when they were cut) would make
>>> dealing with the issue a non-release-critical one for my taste. IOW,
>>> if a new version of Ubuntu showed up after 4.6.1, then fixing the
>>> issue in 4.6.2 (now 4.6.3) would indeed be rather desirable. If,
>>> however, that release was around already at the time 4.6.1 got
>>> cut, then I don't see why this is so urgent a problem to address.
>>
>> And this is exactly what happened -- the version of Ubuntu which breaks
>> is 16.04, which (as the name indicates) came out in April 2016 -- two
>> months after 4.6.1. :-)
> 
> In which case I don't really follow what you tried to point out with
> the first sentence of your earlier reply still visible above.

I should have said, "tagged 4.6.2".  My point was, there already was a
lot of testing done for 4.6.2; the tag was done with all the care that
can be reasonably expected.

 -George

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

Re: Next 4.6.x stable release, numbering, qemu-tag

[Jan Beulich]

>>> On 15.06.16 at 12:30, <george.dunlap@citrix.com> wrote:
> On 15/06/16 11:25, Jan Beulich wrote:
>>>>> On 15.06.16 at 12:13, <george.dunlap@citrix.com> wrote:
>>> On 15/06/16 11:04, Jan Beulich wrote:
>>>>>>> On 15.06.16 at 11:35, <george.dunlap@citrix.com> wrote:
>>>>> The version of qemu-xen that was tagged with 4.6 had been through
>>>>> several rounds of RCs, months of osstesting, and even through a slew of
>>>>> builds on Travis (which does build Ubuntu, but apparently just not the
>>>>> bleeding-edge version).  I only happened to notice it as I was trying to
>>>>> get patches for raisin for 4.7.
>>>>
>>>> The mere fact that 4.6.0 and 4.6.1 exhibited the same issue (and,
>>>> from what you're saying now, which is different from what I've
>>>> understood before, already did when they were cut) would make
>>>> dealing with the issue a non-release-critical one for my taste. IOW,
>>>> if a new version of Ubuntu showed up after 4.6.1, then fixing the
>>>> issue in 4.6.2 (now 4.6.3) would indeed be rather desirable. If,
>>>> however, that release was around already at the time 4.6.1 got
>>>> cut, then I don't see why this is so urgent a problem to address.
>>>
>>> And this is exactly what happened -- the version of Ubuntu which breaks
>>> is 16.04, which (as the name indicates) came out in April 2016 -- two
>>> months after 4.6.1. :-)
>> 
>> In which case I don't really follow what you tried to point out with
>> the first sentence of your earlier reply still visible above.
> 
> I should have said, "tagged 4.6.2".  My point was, there already was a
> lot of testing done for 4.6.2; the tag was done with all the care that
> can be reasonably expected.

Okay, maybe I'm confused then. I had thought all of this was a result
of the thread titled "compilation fail, xen staging-4.6, vnc.c,
qemu-tradintional issues under ubuntu 16.04", which aiui has its origin
in March.

Jan


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

Re: Next 4.6.x stable release, numbering, qemu-tag

[George Dunlap]

On 15/06/16 11:46, Jan Beulich wrote:
>>>> On 15.06.16 at 12:30, <george.dunlap@citrix.com> wrote:
>> On 15/06/16 11:25, Jan Beulich wrote:
>>>>>> On 15.06.16 at 12:13, <george.dunlap@citrix.com> wrote:
>>>> On 15/06/16 11:04, Jan Beulich wrote:
>>>>>>>> On 15.06.16 at 11:35, <george.dunlap@citrix.com> wrote:
>>>>>> The version of qemu-xen that was tagged with 4.6 had been through
>>>>>> several rounds of RCs, months of osstesting, and even through a slew of
>>>>>> builds on Travis (which does build Ubuntu, but apparently just not the
>>>>>> bleeding-edge version).  I only happened to notice it as I was trying to
>>>>>> get patches for raisin for 4.7.
>>>>>
>>>>> The mere fact that 4.6.0 and 4.6.1 exhibited the same issue (and,
>>>>> from what you're saying now, which is different from what I've
>>>>> understood before, already did when they were cut) would make
>>>>> dealing with the issue a non-release-critical one for my taste. IOW,
>>>>> if a new version of Ubuntu showed up after 4.6.1, then fixing the
>>>>> issue in 4.6.2 (now 4.6.3) would indeed be rather desirable. If,
>>>>> however, that release was around already at the time 4.6.1 got
>>>>> cut, then I don't see why this is so urgent a problem to address.
>>>>
>>>> And this is exactly what happened -- the version of Ubuntu which breaks
>>>> is 16.04, which (as the name indicates) came out in April 2016 -- two
>>>> months after 4.6.1. :-)
>>>
>>> In which case I don't really follow what you tried to point out with
>>> the first sentence of your earlier reply still visible above.
>>
>> I should have said, "tagged 4.6.2".  My point was, there already was a
>> lot of testing done for 4.6.2; the tag was done with all the care that
>> can be reasonably expected.
> 
> Okay, maybe I'm confused then. I had thought all of this was a result
> of the thread titled "compilation fail, xen staging-4.6, vnc.c,
> qemu-tradintional issues under ubuntu 16.04", which aiui has its origin
> in March.

Indeed, that thread did show up in March, and the author said he was
building against 16.04, even though Google tells  me Ubuntu 16.04 wasn't
released until 21 April 2016.  He must have been using a beta release of it.

And unfortunately his report dropped through the cracks.  The fix from
upstream should have been backported to qemu-xen at that point, but it
(apparently) didn't come to the attention of the right people.

"Remember all the things you've forgotten or didn't notice" is about as
actionable as "fix all the bugs you don't know exist". :-)

 -George

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