Re: [Qemu-devel] S390 bios breaks in qemu 2.10.rc3

[Michael Roth]

Quoting Thomas Huth (2017-08-29 04:35:22)
> On 28.08.2017 09:18, Christian Borntraeger wrote:
> > 
> > 
> > On 08/25/2017 10:29 AM, Cornelia Huck wrote:
> >> On Fri, 25 Aug 2017 10:21:58 +0200
> >> Christian Borntraeger <address@hidden> wrote:
> >>
> >>> On 08/25/2017 09:20 AM, Cornelia Huck wrote:
> >>
> >>>> OK, to recap:
> >>>>
> >>>> - the current pre-built bios seems fine
> >>>> - rebuilding the bios may yield a version that fails on some systems
> >>>>   (different compiler?)
> >>>> - adding aligned(8) looks like the right thing to do
> >>>> - it seems to fix the problem, but on at least one system something
> >>>>   still seems off (under investigation)  
> >>>
> >>> Yes. I am out of office today, so for any aligned(8) patch
> >>> Acked-by: Christian Borntraeger <address@hidden>
> >>> even for 2.10.
> >>
> >> I fear the 2.10 train has already left the station, but any aligned(8)
> >> patch should be cc:stable.
> > 
> > I think this could be a topic for QEMU summit. Our process of not allowing
> > fixes in rcx without requiring an rc(x+1) seems a bit odd. The Linux kernel
> > style (there are fixes between the last rc and release) seems more balanced
> > as long as we establish some safety nets.
> 
> This sounds like a good idea to me, yes. And maybe we could also ease
> the situation a little bit by providing the first stable .1 release
> already two or three weeks after the .0 release [*] ? Then these "we are
> not 100% sure whether this is a severe blocker or not" patches could
> simply be provided to the public with that .1 release instead of
> blocking the QEMU master branch in freeze state...

I can give it a try for 2.10.1.

At least initially, I would prefer to not have there be a set expectation
that there will be a quick .1 release though, but rather anything tagged
for-2.10, for instance, that doesn't make it in, will then fall into
the "expedited 2.10.1" bucket, and for that to be the *only* way to get
into that bucket (we'd still do the normal round-up and pull in any
"Cc: address@hidden" patches at that point though).

This would help ensure we don't steal focus from the .0 releases and allow
those "is this a blocker?" discussions to happen in the proper context.

> 
>  Thomas
> 
> 
> [*] I know that means more additional work for Michael - sorry for that
> ... but at least we should talk about this, I think. Maybe someone else
> could also help with the releases if it's too much work for one person?
>