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

[Michael Roth]

On 09/01/2017 02:06 AM, Christian Ehrhardt wrote:
> 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?

Correct.

> - but to "get in" you'd still expect all changes that should be
> considered
> to hit "Cc: address@hidden" and be bugfix only?

Well, that's always the case. What I'm suggesting is that for, say,
2.11, we shouldn't plan to have an early 2.11.1, but rather target
everything for 2.11.0 as normal and only do an early 2.11.1 if we
decide to defer anything originally targetted for 2.11.0. Otherwise
2.11.1 would happen toward the end of 2.12 development cycle like we
usually do.

> 
> 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?
>>>
>>
>>
>>
>