qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Christian Ehrhardt
Subject: Re: [Qemu-devel] S390 bios breaks in qemu 2.10.rc3
Date: Fri, 1 Sep 2017 09:06:44 +0200

On Thu, Aug 31, 2017 at 7:44 PM, Michael Roth <address@hidden>
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 <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).
>

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: address@hidden" 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?
> >
>
>
>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]