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

[Alexander Graf]

Am 13.03.2012 um 02:01 schrieb Andreas Färber <address@hidden>:

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

Let's take a real world example from Linux here. 3.3-rc5 had a pretty nasty 
compile bug that made the build break on any 32 bit target when autofs was 
activated. I posted the bug plus a small bugfix upstream.

What happened? Linus went ahead and fixed the thing properly so rc6 could go 
out quickly.

I guess that's what Andreas is trying to say here. Making sure new stuff works, 
fixing uncritical bugs etc is well within a maintainer's responsibility. 
Keeping all the code together is where it boils down to the next, the global 
level, the comitters.

That doesn't mean that any of this is exclusive, but it means that whoever 
works on the global scale of the project - and that's what commit rights mean - 
is oblidged to care about the wellbeing of the whole project as a whole. You 
can't just pick a few subsystems and say "I maintain QEMU but I don't care if 
SH4 breaks". That'd be hypocritical :). The same way I can't say "This is a 
patch in PPC code but because this is a particular implementation I don't care 
about I'll ignore it".

Unfortunately - mainly for historical and political reasons - that subsytem 
thinking happens a lot in QEMU land these days. And I'm not sure how to change 
that. Few people actually care about all aspects of QEMU at the same time.


Alex