On Tue, Nov 3, 2015 at 1:36 PM, Paul Menzel < paulepan...@users.sourceforge.net> wrote:
> Dear coreboot folks, > > > Am Donnerstag, den 29.10.2015, 12:55 -0600 schrieb Martin Roth: > > As the community has grown, so has the need to formalize some of the > > guidelines that the community lives by. When the community was small, > > it was easy to communicate these things just from one person to > > another. > > first of, big thanks go to Martin for writing up the draft! > > […] > > > Expectations contributors should have: > > -------------------------------------- > > * Don't expect that people will review your patch unless you ask them > > to. Adding other people as reviewers is the easiest way. Asking for > > reviews for individual patches in the IRC channel, or by sending a > > direct request to an individual through your favorite messenger is > > usually the best way to get a patch reviewed quickly. > > * Don't expect that your patch will be submitted immediately after > > getting a +2. As stated previously, non-trivial patches should wait > > at least 24 hours before being submitted. > > to get some context, at the coreboot conference in Bonn some people > asked for longer review time to not wake up the next morning seeing > something changed. > > Even then, especially for non-payed developers, I think it’s hard to > stay up to date, so the question is, if the time is long enough. On IRC > somebody even mentioned, that patches should stay up for review for *a > week* before getting merged, so there is enough time people can notice > this. > > To not complicate rules, it probably would be easiest to just ask > around if people are alright with 24 hours. Especially, when people > working on the code get added as reviewers, this should be alright. > > On the other hand, more complicated rules could be drafted. The > following rules just deal with the time issue. I am assuming, that +2 > has been given before and the appropriate announcements are made. > > 1. Commits just touching a board can be submitted after 24 hours. > 2. Commits touch more boards, should stay up for review for a week. > They can be submitted earlier if an announcement to the list about the > urgency has been sent and at least two people have given +2. > There's a catch-22 here: The kinds of patches that could benefit from >24 hours in limbo also tend to be the disruptive kinds that may require additional rebasing or changes should they remain in code review for too long. A lot can happen in a week and disruptive patches bitrot faster than normal ones. 24 hours should be considered a minimum, but I'd say "preferably a few days if possible." A >24hr grace period can be agreed upon by reviewers and the author depending on the complexity to mitigate bitrot. -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc.
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot