<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 3, 2015 at 1:36 PM, Paul Menzel <span dir="ltr"><<a href="mailto:paulepanter@users.sourceforge.net" target="_blank">paulepanter@users.sourceforge.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear coreboot folks,<br>
<br>
<br>
Am Donnerstag, den 29.10.2015, 12:55 -0600 schrieb Martin Roth:<br>
> As the community has grown, so has the need to formalize some of the<br>
> guidelines that the community lives by. When the community was small,<br>
> it was easy to communicate these things just from one person to<br>
> another.<br>
<br>
first of, big thanks go to Martin for writing up the draft!<br>
<br>
[…]<br>
<br>
> Expectations contributors should have:<br>
> --------------------------------------<br>
> * Don't expect that people will review your patch unless you ask them<br>
> to. Adding other people as reviewers is the easiest way. Asking for<br>
> reviews for individual patches in the IRC channel, or by sending a<br>
> direct request to an individual through your favorite messenger is<br>
> usually the best way to get a patch reviewed quickly.<br>
> * Don't expect that your patch will be submitted immediately after<br>
> getting a +2. As stated previously, non-trivial patches should wait<br>
> at least 24 hours before being submitted.<br>
<br>
to get some context, at the coreboot conference in Bonn some people<br>
asked for longer review time to not wake up the next morning seeing<br>
something changed.<br>
<br>
Even then, especially for non-payed developers, I think it’s hard to<br>
stay up to date, so the question is, if the time is long enough. On IRC<br>
somebody even mentioned, that patches should stay up for review for *a<br>
week* before getting merged, so there is enough time people can notice<br>
this.<br>
<br>
To not complicate rules, it probably would be easiest to just ask<br>
around if people are alright with 24 hours. Especially, when people<br>
working on the code get added as reviewers, this should be alright.<br>
<br>
On the other hand, more complicated rules could be drafted. The<br>
following rules just deal with the time issue. I am assuming, that +2<br>
has been given before and the appropriate announcements are made.<br>
<br>
1. Commits just touching a board can be submitted after 24 hours.<br>
2. Commits touch more boards, should stay up for review for a week.<br>
They can be submitted earlier if an announcement to the list about the<br>
urgency has been sent and at least two people have given +2.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div></div><div><br></div>-- <br><div class="gmail_signature">David Hendricks (dhendrix)<br>Systems Software Engineer, Google Inc.</div>
</div></div>