Patch scheduling

[Colin Campbell]

For my guidance, I'd be grateful if the community would correct or 
amplify the following recap of the patch handling process.

Working backwards:

When an MR has been on Countdown for 48 hours, it goes to Push.

When an MR has been or Review for 24 hours, it goes on the next countdown.

When an MR is marked New, and any regression tests seem clean, it goes 
to Review.

When the list of MRs has been scanned, notify the developers, using the 
countdown.py script.

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.

When I've understood the process fully, I'm content to keep performing 
the function, and I'll try to be more careful of where I put my feet.


Thanks to you all for your patience as I come to grips with the system 
and the local lore, written and unwritten.


Cheers,

Colin