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 02:01:33 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120215 Thunderbird/10.0.2

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.

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.

Andreas

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