qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Unclear committer situation


From: Jan-Simon Möller
Subject: Re: [Qemu-devel] Unclear committer situation
Date: Wed, 2 Dec 2009 22:09:19 +0100
User-agent: KMail/1.12.2 (Linux/2.6.31.5-0.1-default; KDE/4.3.1; x86_64; ; )

Am Mittwoch 02 Dezember 2009 09:54:04 schrieb Alexander Graf:
> > 
> > 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.
Full ack on this - we have git, we can always revert without problem.

Make a policy like: at least another pair of eyes has to ack/sign-off and then 
lets commit it.
If a breakage occurs -> just revert, ppl will act.

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

FWIW this is also my impression - IMHO we should adapt a similar process.


my 0.02 €  ... 

best,
Jan-Simon




reply via email to

[Prev in Thread] Current Thread [Next in Thread]