All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] An organizational suggestion
Date: Tue, 03 Jun 2008 15:37:39 -0500	[thread overview]
Message-ID: <4845AB93.2050005@codemonkey.ws> (raw)
In-Reply-To: <18501.23962.985598.92661@mariner.uk.xensource.com>

Ian Jackson wrote:
> Paul Brook writes ("Re: [Qemu-devel] An organizational suggestion"):
>   
>> I'd just like to point out that committing patches is easy. The hard
>> (and time consuming) bit is identifying, rejecting, fixing and/or
>> making constructive comments on all the bogus patches. The are lots
>> of patches that fall into this latter category, e.g. patches that
>> have clearly only ever been tested on x86 targets.
>>     
>
> Yes.
>
>   
>>  It doesn't take any special privileges to do this patch review.
>>     
>
> That's true, but it doesn't tell the whole story.  Anyone can
> criticise a patch (and we do).  But while review by a non-committer is
> very helpful, it still doesn't mean that the committer doesn't have to
> do review of their own.  After all the committer is actually the
> gatekeeper and has the personal responsibility to commit good code.
>
> Also, review and improvement of patches by non-committer contributors
> depends on the contributors' expectation that patch will be accepted
> when it is good.  There is no point in people reviewing and commenting
> on and improving patches if the maintainers don't have the time or
> inclination to get those refined patches actually reviewed by them and
> committed.
>   

Here's a couple things I notice that often cause a patch to be dropped:

1) It has something wrong, but not sufficiently interesting enough for 
anyone to offer feedback

2) It has something wrong, there's a thread with discussion and 
resubmissions of the patch, and the thread eventually cools off with a 
patch people are happy with

3) It's lost in the noise

#3 is something that happens.  A contributer has to resend patches to 
any project.  I don't think this happens very often on QEMU.

More often, I think the problem is #1.  This is something that we all 
can fix by just reviewing patches.  This has been an important issue for 
a while now and I'm willing to dedicate a portion of my time to 
reviewing patches.  For anyone submitting a patch to qemu-devel, feel 
free to CC me to make sure I review it.  I'm not saying that my review 
will guarantee acceptance, but I will keep track of patches I've reviewed.

#2 is a process problem.  It's unclear in this sort of thread, who's 
happy with the patch, and whether a conclusion has been reached.  The 
best thing to do is here to make use of Reviewed-by or Acked-by tags and 
to resubmit the patch as a top-level posting once consensus has been 
reached.

With a few more people dedicating time to patch review I think we can 
improve things quite a bit.

Regards,

Anthony Liguori

  parent reply	other threads:[~2008-06-03 20:37 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-03  5:42 [Qemu-devel] An organizational suggestion Balazs Attila-Mihaly (Cd-MaN)
2008-06-03  9:27 ` Ian Jackson
2008-06-03 10:00   ` Jamie Lokier
2008-06-03 10:19     ` Ian Jackson
2008-06-03 11:03       ` Jamie Lokier
2008-06-03 12:32         ` Ian Jackson
2008-06-03 13:01           ` [Qemu-devel] " Jan Kiszka
2008-06-03 14:26             ` Jamie Lokier
2008-06-03 22:24           ` [Qemu-devel] " Anthony Liguori
2008-06-03 13:45       ` Johannes Schindelin
2008-06-03 14:02         ` Ian Jackson
2008-06-03 14:35           ` Paul Brook
2008-06-03 14:41             ` Jamie Lokier
2008-06-03 14:55               ` Paul Brook
2008-06-03 15:14                 ` Jamie Lokier
2008-06-03 14:54             ` Laurent Vivier
2008-06-03 15:04             ` Ian Jackson
2008-06-03 15:17               ` Jamie Lokier
2008-06-03 15:27                 ` Ian Jackson
2008-06-03 16:54                   ` Anthony Liguori
2008-06-03 19:26                   ` Jamie Lokier
2008-06-03 15:24               ` Laurent Vivier
2008-06-03 20:37               ` Anthony Liguori [this message]
2008-06-03 20:27           ` Anthony Liguori
2008-06-03 10:23     ` Andreas Färber
2008-06-03 11:09       ` [Qemu-devel] " Jan Kiszka
2008-06-03 12:36         ` Ian Jackson
2008-06-03 12:48           ` Daniel P. Berrange
  -- strict thread matches above, loose matches on Subject: below --
2008-06-03 10:11 [Qemu-devel] " Balazs Attila-Mihaly (Cd-MaN)
2008-06-03 15:36 Balazs Attila-Mihaly (Cd-MaN)
2008-06-03 16:59 ` Andreas Färber

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=4845AB93.2050005@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --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.