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 <borntrae...@de.ibm.com> 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 <borntrae...@de.ibm.com> > >>> 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: qemu-sta...@nongnu.org" 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? >
