Re: [Qemu-devel] Unclear committer situation

[Alexander Graf]

On 02.12.2009, at 09:46, Aurelien Jarno wrote:

> On Wed, Dec 02, 2009 at 09:37:16AM +0100, Alexander Graf wrote:
>> 
>> On 02.12.2009, at 09:26, Aurelien Jarno wrote:
>> 
>>> On Tue, Dec 01, 2009 at 12:47:36PM +0100, Alexander Graf wrote:
>>>> Hi,
>>>> 
>>>> Could someone with commit rights please stand up to feel responsible for 
>>>> PPC?
>>>> 
>>>> Usually, when I send a patch to qemu-devel, I know who to address to  
>>>> increase chances of it getting committed. For kvm/vnc/block I just CC  
>>>> Anthony, for Audio I just CC malc, etc.
>>>> 
>>>> There are some subsystems where nobody feels responsible though,  
>>>> apparently hoping 'someone else' will tske on it. Well, turns out it  
>>>> doesn't work that way.
>>>> 
>>>> So could we please assign a committer for every subsystem around? Even  
>>>> if the committer doesn't know the architecture inside out, it's still  
>>>> valuable to have soneone feel responsible at all. Committer and  
>>>> maintainer also don't have to be the same person. I'll gladly maintain  
>>>> S390 without having commit rights - as long as I have someone to CC and 
>>>> know the patches will get merged.
>>>> 
>>> 
>>> I also try to follow the ppc architecture, though less than mips and
>>> also depending on my free time. I know that Blue Swirl and Malc also
>>> care about it.
>> 
>> Right - which makes it pretty hard. IMHO it's always best to have a single 
>> person to talk to when it comes to committing and others who comment on 
>> patches.
> 
> Some committers are not available for a long period of time. It also
> happens to me.

So we need a clear backup strategy. Something like that when you know you're 
not available for > 4 days, you assign someone else to be your replacement for 
that timeframe.

>> In fact, I even believe that the person committing stuff doesn't have to 
>> know the stuff he commits. If I make a patch that breaks S390 and someone 
>> commits it, it's my fault breaking it - not the committer's. If I do a patch 
>> breaking PPC KVM, it's my fault breaking it, not the committer's. And with 
>> fault I also mean "responsibility to fix".
> 
> Experience has shown that it doesn't work like that. It happens the
> person writing the patches never provides a fix, and the committer
> receives the complains, and in fine fixes the commit.

Then revert the patch. I also think we need to distinguish subsystems here.

So when you have something really core-y - like the main loop - then of course 
you go through a lot of review and try to get a lot of people involved, so it 
doesn't break.

On the other hand if you have a subsystem that is completely separate - like 
cris - you don't care if it's broken. If it is for > 24 hours, exclude it from 
the default build list. If you see that one person breaks stuff all along, 
tighten the restrictions for that person. But that doesn't mean all subsystems 
need a review as thorough as the core code.

In fact, it is a _lot_ easier to get code into Linux than it is to get it into 
Qemu. That's just plain wrong.

>>> It's not impossible that I miss patches given the current patches rate
>>> on the mailing list, so don't hesitate to Cc: me. On the other hand, I
>>> don't really feel comfortable with KVM related patches, I would prefer
>>> to see them committed by Anthony.
>> 
>> Avi, can I get PPC KVM patches in through you then? I guess you're the 
>> closest person to the code in question.
>> 
> 
> If you an get your patches acked-by Avi, I am fine merging them.

Cool, thanks!

Alex