Re: [Qemu-devel] [RFC] QEMU Code Audit Team

[Kevin Wolf <kwolf@redhat.com>]

Am 07.01.2012 11:42, schrieb Stefan Hajnoczi:
> On Sat, Jan 7, 2012 at 3:09 AM, Peter Maydell <peter.maydell@linaro.org> wrote:
>> On 6 January 2012 20:42, Anthony Liguori <aliguori@us.ibm.com> wrote:
>>> On 01/06/2012 02:02 PM, Andreas Färber wrote:
>>>> i) Unless it's a build fix, I propose defining a minimum review time
>>>> before a patch is applied to a (sub)maintainer's queue.
>>
>>> I disagree here.  If anything, I think we wait a bit too long for people to
>>> review things and that prevents progress.
>>
>> Actually I think it would be useful to agree on a "standard" time
>> for this kind of thing. A lot of the ARM related patches I do don't
>> get review, and it would be nice to know how long it's sensible to wait
>> until I can submit them in a pull request. (I don't want to cut
>> short time for people to review, but I don't want them languishing
>> on the list for weeks either...)
> 
> I typically ping if there has been no activity for 1 week or more.
> 
> Introducing a wait period of more than a few days is probably not
> going to add much review, perhaps the usual reviewers will just put
> off reviewing until closer to the deadline.  Something like 2 days is
> reasonable though, IMO.

What would this wait period really mean? If there hasn't been any review
within 2 day, the patch is considered correct and committed without any
review? Or is it the earliest that a maintainer may pick it up and do
the work himself?

Currently I usually apply patches when I have reviewed them, because I
know that very likely nobody else is going to review them anyway. This
can be as little as a few hours (though recently it's more often a few
weeks...). Then you have some time left to object until I actually send
the pull request, which isn't a fixed date either.

I can understand if you want to have more predictable times, but really,
when nobody else is going to review it anyway, what use would it be to
create even more management overhead for me?

Probably we need to attack the reviewing problem first: That I review
all block patches myself worked well as long as we were two or three
people in that area, but today it doesn't scale any more without
lowering the review standards - and I don't want to do that. Maybe we
should introduce something like "One Reviewed-by buys you two
Signed-off-bys for your own patches" ;-)

I can imagine that other subsystem maintainers have similar problems.

Kevin