Dan Eble <d...@faithful.be> writes: > On Feb 3, 2020, at 04:30, Han-Wen Nienhuys <hanw...@gmail.com> wrote: >> >> Instead of waiting for complaints, a change is >> pushed once it passes tests and someone LGTM'd it. > > I've worked in places where commits were handled with self-discipline > and mutual accountability, and I've worked in places where a UI > enforced upper-management's policy that every change had to be > approved by two other developers before it could be merged. I prefer > self-discipline and mutual accountability to having to nag people with > a superficial understanding of a change to put themselves on record as > approving it. > > Therefore, regarding the countdown, I think it's a bad idea to require > approval before pushing, unless we grant that the patch meister can > approve pushing with the reason "countdown complete." > > Regarding accelerating the process, I wouldn't have a problem with a > developer pushing a change after tests have passed, after receiving > the clear approval of a developer competent in the subject, and when > others aren't likely to disagree. It would take a little more trust > and clarity of feedback than always waiting for the countdown. I > don't expect that it would be the norm.
It does happen, and different developers are differently comfortable taking the responsibility for bypassing the opportunity of feedback depending on the situation. The staging procedure reduces the potential size of consequences of such a step, even in case of completely bypassing any kind of review for trivial changes (trivial typically also implying that no computer-interpreted syntax is changed). It mostly makes sense where it is unexpected others will comment, or when in the course of larger interdependent changes that cannot be defused by rebases, the queue is expected to continue stalling for prolonged amounts of time. -- David Kastrup
