On Thu, Aug 31, 2017 at 7:44 PM, Michael Roth <mdr...@linux.vnet.ibm.com> wrote:
> 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). > Hi Michael, To check if I got that correctly: - a 2.10.1 could happen rather soon (like end of september as suggested) as several things seem still up in the air? - but to "get in" you'd still expect all changes that should be considered to hit "Cc: qemu-sta...@nongnu.org" and be bugfix only? 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? > > > > >
