qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] We need more reviewers/maintainers!!


From: Andreas Färber
Subject: Re: [Qemu-devel] We need more reviewers/maintainers!!
Date: Tue, 13 Mar 2012 00:32:04 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120215 Thunderbird/10.0.2

Am 12.03.2012 22:18, schrieb Anthony Liguori:
> On 03/12/2012 04:12 PM, Stefan Weil wrote:
>> Am 12.03.2012 21:27, schrieb Anthony Liguori:
>>> On 03/12/2012 03:12 PM, Stefan Weil wrote:
>>>> [...] There a many examples of
>>>> urgent patches (= patches which fix broken builds) which take
>>>> several days even when they were reviewed before they finally
>>>> are committed.
>>>
>>> Can you be specific? [...]
>>
>> I don't mean w32 patches only. The last build break was for ppc hosts
>> (e04b28996110bd6acfc059e9f2c8c5aba5119a46, it took more than 5 days),
>> but I remember also situations were x86 was broken more than
>> a day.
>>
>> A selection of older patches which fixed build and the time it took
>> from creation to commit:
>>
>> 6148b23d69444a300710db0c53f6c53b7f3c8067 (kvm ppcm 3 days)
>> 1ecf47bf0a091700e45f1b7d1f5ad85abc0acd22 (w32, 2 days)
> 
> So both of these platforms have maintainers that can do PULL requests
> for issues like this.
[snip]

You're missing the point here: There usually *are* patches quickly, but
they often don't get applied to qemu.git as fast. Often there are even
two or three people sending build fixes concurrently. Do you really need
a PULL for a single patch that affects everyone?

Take Blue's recent target-ppc fix
9d4df9c02866f39d3eef105033091f367cc7c29e for example: After applying
patches on day one of FOSDEM he posted a -Werror fix, it got confirmed
by me and Alex but wasn't applied until a week later, because apparently
no other committer dared to apply Blue's patch despite SoB and acks and
people reporting the issue... Not happy.
No doubt Alex is to blame for not catching that issue in his ppc queue,
but asking Alex as submaintainer to submit a PULL for a single patch
posted by Blue as committer seems overly complicated to me! ;)

If the build gets broken (which I bet will happen even with qemu-test
once in a while, given we all use different compilers) then fixing it
should not be a submaintainer responsibility IMO. If non-obvious how to
fix, then as a maintainer please just revert offending patches and let
the submaintainers fix their PULLs rather than delegating responsibility
for the whole qemu.git build to the submaintainer of the day.

This boils down to the policies question I brought up some weeks ago:
When we have, e.g., a build breakage on the major platform, do
maintainers expect a certain number of reviewers before applying? Or a
fixed timeframe for review? Again, please document these things in the
Wiki so people know what to do and don't just wait for another to act!

Regards,
Andreas

P.S. I know I'm lagging myself, especially for the cocoa queue lately,
but I'm one and in theory there's like seven committers for qemu.git...

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



reply via email to

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