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

[Super Bisquit]

Is there a core group/committee that handles all fixes, code, and what not?



On 3/12/12, Alexander Graf <address@hidden> wrote:
>
>
> 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
>
>
>