Hi Colin,
forgive me for butting in as someone who has made very few contributions
(but followed some of the discussions quite closely over the last few
years):
All the above can be overridden by any developer with access, where
judgement calls for expediting an MR, or it is clearly trivial. MRs
can also be set back in the flow by developers, when issues are found,
or after new commits are added. Open discussions are not necessarily a
reason to hold back an MR.
If all that is reasonably close to the way things operate, the role of
the patch scheduler is pretty mechanical, simply moving MRs into the
next bucket. I remember that a Patch Meister was needed in the old
days of Reitveldt, Savannah, and whatever other platforms were
involved, but it seems that the new, integrated platform, with what
seems to be trustworthy automated and sufficiently rigorous testing,
has changed the flow significantly. The patch scheduling function, and
again, I only describe my outsider's understanding, seems to have
become a cron job running in wetware. It would seem more efficient to
implement a script which would take the same set of decisions, update
labels, and run a modified countdown.py to email the devel list with
results and any anomalous conditions,such as open threads, recent
commits, and the like.
My impression is that that while your summary of the process seems
correct, perhaps you underestimate the considerable worth that comes
with the wetware.
First, some of the rules you stated ("can be overridden by any
developer", "open discussions are not necessarily a reason to hold
back") actually involve judgement calls from all parties involved: For
example, the rule that senior developers (you omitted that admittedly
fuzzy adjective from the CG) may bypass the normal flow only works as
long as it is only ever invoked for non-controversial merges (and to
judge non-controversiality needs quite a bit of experience). The rule
that open discussions are not a rock-solid obstacle for a MR being
merged requires someone - and in my impression, that's something that
James did inconspicuously but thoroughly - to judge whether the open
discussions are of a nature that should delay the process for the MR in
question.
In the case of Dan's merge request
https://gitlab.com/lilypond/lilypond/-/merge_requests/1173 that sparked
this discussion, I agree with Jean that this was a matter of
misunderstanding/miscommunication (starting with the problem that it was
not completely obvious just by reading the messages that the issue Dan
spotted and created was actually only made visible by his MR, not caused
by it).
Also, there are more "soft" factors in play here: For one, the fact that
Dan's MR comes from someone who has constantly churned out high-quality
code contributions for many years now, who is just not very likely to
try and ill-advisedly force a MR through by brute force. Also, there has
been both a very high level of activity on GitLab where people like
Jean, Werner and others did a marvelous job of reviewing new code (and
miraculously leading to only very, very few discussions of the more
emotionally heated type), which made it possible to actually regard
"silence on a MR" as being quite close to "approval". Again, this is
something that is too dependent on factors that might change at some
point in the future to allow for it to be turned into a written rule.
So what I'm trying to say is: A task that seems like a trivial cron job
95% of the time may very well require human intelligence, tact and
judgement in the remaining 5 %. (And I haven't even mentioned yet the
"human factor" that would be sorely missed of the question "Folks, is
this ready now or should we keep it on review?" came from a script
instead of from you or, formerly, James.)
Lukas
