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

[Blue Swirl]

On Tue, Mar 13, 2012 at 01:01, Andreas Färber <address@hidden> wrote:
> Am 13.03.2012 01:16, schrieb Anthony Liguori:
>> On 03/12/2012 06:32 PM, Andreas Färber wrote:
>>> 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! ;)
>>
>> I think this is a good demonstration of what the problem is.  Unclear
>> responsibility.
>
> Agreed. Solution is documentation of expected workflows.
>
>>  I'm pretty sure that Blue thought that Alex would
>> handle the patch.  I'm pretty sure that Alex thought Blue would handle
>> the patch.
>
> Alex actually asked Blue to.
>
> However from what I understand, Blue is not working on QEMU full-time,
> like me previously. I assume he handled the patch once he read and came
> around to it. It's just that no one else with commit powers reacted to
> the situation.

Real life can be pretty demanding at times.

I can't imagine when I would mind if somebody else applied patches
I've sent if they are not RFC.

> The way I see it no one "owns" code in QEMU. Some people feel
> responsible for (or comfortable reviewing changes to) parts of QEMU, and
> the project scales by distributing review, testing and queuing to more
> such shoulders.
> However where a (sub)maintainer is unresponsive - and *there* I
> differentiate between build breakages, runtime issues and feature
> additions - we can't wait forever and need to adapt processes. Fixing
> the build within a reasonable time is one requirement, moving forward
> with target-mips at all is another example.
>
> It's not really that we have too few maintainers, it's that not all
> maintainers maintain at all times - for valid work or personal reasons -
> and we don't seem to have a well-working escalation mechanism beyond
> ping^n to handle that.

This particular issue could have been avoided with more thorough
compile testing by me before pushing Alex's PPC tree, or by Alex
himself before submitting d1e256fe.

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