[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 15.06.16 at 11:35, <george.dunlap@xxxxxxxxxx> 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@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®.