* Next 4.6.x stable release, numbering, qemu-tag [not found] ` <22362.58894.967258.687430@mariner.uk.xensource.com> @ 2016-06-14 17:57 ` Ian Jackson 2016-06-14 19:27 ` Konrad Rzeszutek Wilk 2016-06-15 7:38 ` Jan Beulich 0 siblings, 2 replies; 15+ messages in thread From: Ian Jackson @ 2016-06-14 17:57 UTC (permalink / raw) To: Jan Beulich, Anthony PERARD, Stefano Stabellini, Lars Kurth Cc: xen-devel, committers, Doug Goldstein 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Next 4.6.x stable release, numbering, qemu-tag 2016-06-14 17:57 ` Next 4.6.x stable release, numbering, qemu-tag Ian Jackson @ 2016-06-14 19:27 ` Konrad Rzeszutek Wilk 2016-06-15 8:57 ` George Dunlap 2016-06-15 7:38 ` Jan Beulich 1 sibling, 1 reply; 15+ messages in thread From: Konrad Rzeszutek Wilk @ 2016-06-14 19:27 UTC (permalink / raw) To: Ian Jackson Cc: Stefano Stabellini, Lars Kurth, Doug Goldstein, committers, Jan Beulich, Anthony PERARD, xen-devel > 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Next 4.6.x stable release, numbering, qemu-tag 2016-06-14 19:27 ` Konrad Rzeszutek Wilk @ 2016-06-15 8:57 ` George Dunlap 2016-06-15 9:51 ` Jan Beulich 0 siblings, 1 reply; 15+ messages in thread From: George Dunlap @ 2016-06-15 8:57 UTC (permalink / raw) To: Konrad Rzeszutek Wilk, Ian Jackson Cc: Stefano Stabellini, Lars Kurth, Doug Goldstein, committers, Jan Beulich, Anthony PERARD, xen-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Next 4.6.x stable release, numbering, qemu-tag 2016-06-15 8:57 ` George Dunlap @ 2016-06-15 9:51 ` Jan Beulich 0 siblings, 0 replies; 15+ messages in thread From: Jan Beulich @ 2016-06-15 9:51 UTC (permalink / raw) To: George Dunlap, Konrad Rzeszutek Wilk Cc: Stefano Stabellini, Lars Kurth, Doug Goldstein, Ian Jackson, committers, Anthony PERARD, xen-devel >>> 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Next 4.6.x stable release, numbering, qemu-tag 2016-06-14 17:57 ` Next 4.6.x stable release, numbering, qemu-tag Ian Jackson 2016-06-14 19:27 ` Konrad Rzeszutek Wilk @ 2016-06-15 7:38 ` Jan Beulich 2016-06-15 9:03 ` Wei Liu 2016-06-15 9:35 ` George Dunlap 1 sibling, 2 replies; 15+ messages in thread From: Jan Beulich @ 2016-06-15 7:38 UTC (permalink / raw) To: Ian Jackson, Lars Kurth Cc: Anthony PERARD, xen-devel, Stefano Stabellini, DougGoldstein, committers >>> 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Next 4.6.x stable release, numbering, qemu-tag 2016-06-15 7:38 ` Jan Beulich @ 2016-06-15 9:03 ` Wei Liu 2016-06-15 9:56 ` Jan Beulich 2016-06-15 9:35 ` George Dunlap 1 sibling, 1 reply; 15+ messages in thread From: Wei Liu @ 2016-06-15 9:03 UTC (permalink / raw) To: Jan Beulich Cc: Stefano Stabellini, Wei Liu, Lars Kurth, Ian Jackson, DougGoldstein, committers, Anthony PERARD, xen-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Next 4.6.x stable release, numbering, qemu-tag 2016-06-15 9:03 ` Wei Liu @ 2016-06-15 9:56 ` Jan Beulich 2016-06-15 10:21 ` Wei Liu 0 siblings, 1 reply; 15+ messages in thread From: Jan Beulich @ 2016-06-15 9:56 UTC (permalink / raw) To: Wei Liu Cc: Stefano Stabellini, Lars Kurth, DougGoldstein, Ian Jackson, committers, Anthony PERARD, xen-devel >>> 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Next 4.6.x stable release, numbering, qemu-tag 2016-06-15 9:56 ` Jan Beulich @ 2016-06-15 10:21 ` Wei Liu 0 siblings, 0 replies; 15+ messages in thread From: Wei Liu @ 2016-06-15 10:21 UTC (permalink / raw) To: Jan Beulich Cc: Stefano Stabellini, Wei Liu, Lars Kurth, Ian Jackson, DougGoldstein, committers, Anthony PERARD, xen-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Next 4.6.x stable release, numbering, qemu-tag 2016-06-15 7:38 ` Jan Beulich 2016-06-15 9:03 ` Wei Liu @ 2016-06-15 9:35 ` George Dunlap 2016-06-15 10:04 ` Jan Beulich 1 sibling, 1 reply; 15+ messages in thread From: George Dunlap @ 2016-06-15 9:35 UTC (permalink / raw) To: Jan Beulich, Ian Jackson, Lars Kurth Cc: Anthony PERARD, xen-devel, Stefano Stabellini, DougGoldstein, committers 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Next 4.6.x stable release, numbering, qemu-tag 2016-06-15 9:35 ` George Dunlap @ 2016-06-15 10:04 ` Jan Beulich 2016-06-15 10:13 ` George Dunlap 0 siblings, 1 reply; 15+ messages in thread From: Jan Beulich @ 2016-06-15 10:04 UTC (permalink / raw) To: George Dunlap Cc: Stefano Stabellini, Lars Kurth, DougGoldstein, Ian Jackson, committers, Anthony PERARD, xen-devel >>> 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Next 4.6.x stable release, numbering, qemu-tag 2016-06-15 10:04 ` Jan Beulich @ 2016-06-15 10:13 ` George Dunlap 2016-06-15 10:25 ` Jan Beulich 0 siblings, 1 reply; 15+ messages in thread From: George Dunlap @ 2016-06-15 10:13 UTC (permalink / raw) To: Jan Beulich Cc: Stefano Stabellini, Lars Kurth, DougGoldstein, Ian Jackson, committers, Anthony PERARD, xen-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Next 4.6.x stable release, numbering, qemu-tag 2016-06-15 10:13 ` George Dunlap @ 2016-06-15 10:25 ` Jan Beulich 2016-06-15 10:30 ` George Dunlap 0 siblings, 1 reply; 15+ messages in thread From: Jan Beulich @ 2016-06-15 10:25 UTC (permalink / raw) To: George Dunlap Cc: Stefano Stabellini, LarsKurth, DougGoldstein, Ian Jackson, committers, Anthony PERARD, xen-devel >>> 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Next 4.6.x stable release, numbering, qemu-tag 2016-06-15 10:25 ` Jan Beulich @ 2016-06-15 10:30 ` George Dunlap 2016-06-15 10:46 ` Jan Beulich 0 siblings, 1 reply; 15+ messages in thread From: George Dunlap @ 2016-06-15 10:30 UTC (permalink / raw) To: Jan Beulich Cc: Stefano Stabellini, LarsKurth, DougGoldstein, Ian Jackson, committers, Anthony PERARD, xen-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Next 4.6.x stable release, numbering, qemu-tag 2016-06-15 10:30 ` George Dunlap @ 2016-06-15 10:46 ` Jan Beulich 2016-06-15 11:46 ` George Dunlap 0 siblings, 1 reply; 15+ messages in thread From: Jan Beulich @ 2016-06-15 10:46 UTC (permalink / raw) To: George Dunlap Cc: Stefano Stabellini, LarsKurth, DougGoldstein, Ian Jackson, committers, Anthony PERARD, xen-devel >>> 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Next 4.6.x stable release, numbering, qemu-tag 2016-06-15 10:46 ` Jan Beulich @ 2016-06-15 11:46 ` George Dunlap 0 siblings, 0 replies; 15+ messages in thread From: George Dunlap @ 2016-06-15 11:46 UTC (permalink / raw) To: Jan Beulich Cc: Stefano Stabellini, LarsKurth, DougGoldstein, Ian Jackson, committers, Anthony PERARD, xen-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2016-06-15 11:47 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <57504E0802000078000F1164@prv-mh.provo.novell.com> [not found] ` <20160602140958.GX5160@citrix.com> [not found] ` <575A868402000078000F3D98@prv-mh.provo.novell.com> [not found] ` <22362.38888.298368.190872@mariner.uk.xensource.com> [not found] ` <22362.40282.345007.208511@mariner.uk.xensource.com> [not found] ` <20160610110551.GA1807@perard> [not found] ` <22362.40839.475210.399639@mariner.uk.xensource.com> [not found] ` <575ACFC902000078000F3F49@prv-mh.provo.novell.com> [not found] ` <22362.47886.957478.714311@mariner.uk.xensource.com> [not found] ` <575AEA4802000078000F3FC8@prv-mh.provo.novell.com> [not found] ` <22362.58894.967258.687430@mariner.uk.xensource.com> 2016-06-14 17:57 ` Next 4.6.x stable release, numbering, qemu-tag Ian Jackson 2016-06-14 19:27 ` Konrad Rzeszutek Wilk 2016-06-15 8:57 ` George Dunlap 2016-06-15 9:51 ` Jan Beulich 2016-06-15 7:38 ` Jan Beulich 2016-06-15 9:03 ` Wei Liu 2016-06-15 9:56 ` Jan Beulich 2016-06-15 10:21 ` Wei Liu 2016-06-15 9:35 ` George Dunlap 2016-06-15 10:04 ` Jan Beulich 2016-06-15 10:13 ` George Dunlap 2016-06-15 10:25 ` Jan Beulich 2016-06-15 10:30 ` George Dunlap 2016-06-15 10:46 ` Jan Beulich 2016-06-15 11:46 ` George Dunlap
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).