From: "Jan-Simon Möller" <dl9pf@gmx.de>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Unclear committer situation
Date: Wed, 2 Dec 2009 22:09:19 +0100 [thread overview]
Message-ID: <200912022209.19776.dl9pf@gmx.de> (raw)
In-Reply-To: <26CFFD5A-A76D-4B6D-88FF-6106AA1D643B@suse.de>
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
next prev parent reply other threads:[~2009-12-02 21:09 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-01 11:47 [Qemu-devel] Unclear committer situation Alexander Graf
2009-12-01 18:51 ` Anthony Liguori
2009-12-01 19:21 ` Blue Swirl
2009-12-01 21:08 ` Anthony Liguori
2009-12-01 22:49 ` Alexander Graf
2009-12-02 11:18 ` andrzej zaborowski
2009-12-02 11:24 ` Alexander Graf
2009-12-02 12:38 ` Avi Kivity
2009-12-02 11:31 ` Riku Voipio
2009-12-03 14:04 ` Anthony Liguori
2009-12-02 8:26 ` Aurelien Jarno
2009-12-02 8:37 ` Alexander Graf
2009-12-02 8:46 ` Aurelien Jarno
2009-12-02 8:54 ` Alexander Graf
2009-12-02 21:09 ` Jan-Simon Möller [this message]
2009-12-02 9:08 ` Avi Kivity
2009-12-02 8:45 ` malc
2009-12-02 15:33 ` Artyom Tarasenko
2009-12-02 18:31 ` [Qemu-devel] " Jan Kiszka
2009-12-02 18:48 ` Artyom Tarasenko
2009-12-03 10:20 ` Michael S. Tsirkin
2009-12-03 13:10 ` andrzej zaborowski
2009-12-02 21:18 ` Anthony Liguori
2009-12-03 10:07 ` Artyom Tarasenko
2009-12-02 18:40 ` [Qemu-devel] " Anthony Liguori
2009-12-02 18:53 ` Artyom Tarasenko
2009-12-02 18:56 ` Alexander Graf
2009-12-03 9:44 ` Filip Navara
2009-12-03 14:19 ` Anthony Liguori
2009-12-02 19:12 ` Anthony Liguori
2009-12-03 9:20 ` Riku Voipio
2009-12-03 12:56 ` Carl-Daniel Hailfinger
2009-12-03 14:40 ` [Qemu-devel] " Michael S. Tsirkin
2009-12-05 0:25 ` [Qemu-devel] " Isaku Yamahata
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200912022209.19776.dl9pf@gmx.de \
--to=dl9pf@gmx.de \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.