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