On Tue, Nov 3, 2015 at 1:36 PM, Paul Menzel <paulepanter@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.