[prev in list] [next in list] [prev in thread] [next in thread] 

List:       qemu-ppc
Subject:    Re: [PATCH v4 0/7] Pegasos2 fixes and audio output support
From:       BALATON Zoltan <balaton () eik ! bme ! hu>
Date:       2023-02-28 17:14:23
Message-ID: 88ffe803-b5d3-da6f-9e52-00e6dd9cf092 () eik ! bme ! hu
[Download RAW message or body]


On Tue, 28 Feb 2023, Daniel P. Berrangé wrote:
> On Tue, Feb 28, 2023 at 04:05:30PM +0100, BALATON Zoltan wrote:
>> On Mon, 27 Feb 2023, Philippe Mathieu-Daudé wrote:
>>> On 27/2/23 18:47, BALATON Zoltan wrote:
>>>> On Mon, 27 Feb 2023, Bernhard Beschow wrote:
>>>>> Unfortunately my patches had changes merged in. This now makes it hard to
>>>>> show what really changed (spoiler: nothing that affects behavior).
>>>>>
>>>>> As you probably noticed in the "resend" version of this iteration I split
>>>>> off a patch introducing the priq properties. It belongs to the sub series
>>>>> of the Pegasos2 IRQ fixes which appear unnecessary to me, so I don't want
>>>>> to show up in `git blame` as the author of any of these changes. I
>>>>> attributed it to you because this was really your change which
>>>>> I'm not even
>>>>> sure is legal.
>>>>>
>>>>> Let's avoid such complications by keeping our series separate.
>>>>
>>>> Let's cool down a bit. Philippe took some of the sm501 patches in
>>>> his giant pull request (and a lot of your patches too) now so I'll
>>>> wait until that lands and hope to get some review for the remaining
>>>> patches too. Once that pull req is merged I'll rebase the remaining
>>>> patches and resubmit the series also adding changes for reasonable
>>>> review comments I get by then.
>>>
>>> I'm sorry it took me so long, I was expecting these patches to be picked
>>> up by other maintainers but everybody is very busy. I know you'll need
>>
>> You have no reason to apologise really, you did a great job merging all the
>> patches. I was thinking that because as you say every maintainer is very
>> busy now and we also had CI outage for a few weeks should we consider
>> extending the date until the freeze by one or two weeks? That would allow
>> people to relax a bit and be able to consolidate and merge all still pending
>> patches. Postponing the 8.0 release one or two weeks is probably better than
>> missing a lot of changes until the next release in September. We'd still aim
>> for the original freeze date but if we fail to meet that it would be more
>> convenient to know there could be a possibility for extending it. But make
>> it clear that this is only for this one time because of CI outage and
>> additional maintainer load caused by that so not something that should be
>> done regularly but under current circumstances I would consider it.
>
> There's no need to change the release schedule IMHO. Subsystem maintainers
> should continue to send pull requests as normal. Peter is still processing
> PRs, albeit at a lower rate with adhoc CI. From the soft freeze POV what
> matters is just that the PRs are posted on the mailing list before the
> deadline. If they're posted in time, they're still valid for inclusion in
> the release. Our CI allowance is reset at the end of today anyway.

Problem is that some patches will need to be rebased on still pending pull 
request and also may need the maintainer's attention to review them and 
send the final pull despite series have been on the list few weeks before 
the freeze that should be in time. So this will mean we might still have 
some pending patches end of this week and if somebody asks for last minute 
changes then it will be hard to meet the deadline. So at least one week 
extension seems to resolve the pressure this causes and also give 
maintainers some time to catch up. It's better than just saying "Sorry it 
was out fault but you've still missed the release, see you next time."

Regards,
BALATON Zoltan

[prev in list] [next in list] [prev in thread] [next in thread]