Re: Patch scheduling

[Lukas-Fabian Moser]

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