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 Borntraeger
Subject: Re: [Qemu-devel] S390 bios breaks in qemu 2.10.rc3
Date: Tue, 29 Aug 2017 12:28:26 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0


On 08/29/2017 11:35 AM, Thomas Huth wrote:
> 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 [*] ?

+1

> 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...
> 
>  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]