Am 07.01.2012 11:42, schrieb Stefan Hajnoczi: > On Sat, Jan 7, 2012 at 3:09 AM, Peter Maydell <peter.mayd...@linaro.org> > wrote: >> On 6 January 2012 20:42, Anthony Liguori <aligu...@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