Patrick Georgi has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/43484 )
Change subject: Documentation: Revise "24 hours wait period" rules ......................................................................
Documentation: Revise "24 hours wait period" rules
They're more or less the same but reworked for hopefully some more clarity. There have been some best practices around documenting the reason for expedited processing so let's make them official, too.
Change-Id: I620e48016a1ceda2ac43f26624ed21af01f6a0a5 Signed-off-by: Patrick Georgi pgeorgi@google.com --- M Documentation/getting_started/gerrit_guidelines.md 1 file changed, 19 insertions(+), 9 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/84/43484/1
diff --git a/Documentation/getting_started/gerrit_guidelines.md b/Documentation/getting_started/gerrit_guidelines.md index 59f675a..5824b17 100644 --- a/Documentation/getting_started/gerrit_guidelines.md +++ b/Documentation/getting_started/gerrit_guidelines.md @@ -43,15 +43,25 @@ clarification, see the Developer's Certificate of Origin in the coreboot [Signed-off-by policy](https://www.coreboot.org/Development_Guidelines#Sign-off_Procedure).
-* Let non-trivial patches sit in a review state for at least 24 hours -before submission. Remember that there are coreboot developers in timezones -all over the world, and everyone should have a chance to contribute. -Trivial patches would be things like whitespace changes or spelling fixes, -in general those that don’t impact the final binary output. The -24-hour period would start at submission, and would be restarted at any -update which significantly changes any part of the patch. Patches can be -'Fast-tracked' and submitted in under 24 hours with the agreement of at -least 3 +2 votes. +* In general, patches should remain open for review for at least 24 hours +since the last significant modification to the change. The purpose is to +let coreboot developers around the world have a chance to review. Complex +reworks, even if they don't change the purpose of the patch but the way +it's implemented, should restart the wait period. + +* A change can go in without the wait period if its purpose is to fix a +recently introduced build or boot issue. Its commit message should explain +what change introduced the problem and the nature of the problem. The +change itself should be as limited in scope and impact as possible +to make it simple to assess the impact. Such a change can be merged +early with 3 Code-Review+2, ideally not all from the same organization, +although that's not a hard requirement. + +* Trivial changes that deal with minor issues like inconsistencies in +whitespace or spelling fixes that don't impact the final binary output +also don't need to wait. Such changes should point out in their commit +messages that they're trivial and also how they verified that the binary +output is identical (e.g. a TIMELESS build for a given configuration).
* Do not +2 patches that you authored or own, even for something as trivial as whitespace fixes. When working on your own patches, it’s easy to