Kyösti Mälkki has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/43484 )
Change subject: Documentation: Revise "24 hours wait period" rules ......................................................................
Patch Set 3:
(1 comment)
https://review.coreboot.org/c/coreboot/+/43484/3/Documentation/getting_start... File Documentation/getting_started/gerrit_guidelines.md:
https://review.coreboot.org/c/coreboot/+/43484/3/Documentation/getting_start... PS3, Line 59: from the same organization, although that's not a hard requirement. When there is no enforcement of documentation policies, the quality of commit messages becomes a major factor for understanding design concepts. Therefore reviewers should be made aware beforehand that fast-tracking is to be expected. Reviewers themselves should self-assess if they are in their comfort-zone to allow fast-tracking.
So what should be done when this fast-tracking backfires? Who should have the responsibility of answering and addressing the questions that appeared after the submit? There are times when simple revert could be the choice, often other dependencies prevent from doing this.
Workarounds don't just magically get fixed upstream. When a commit was identified as such, should it be compulsory to add it to issue-tracker and assigned with a due-date?