The following proposal is intended to address issues in the current process for Besu Maintainers to propose off-cycle, delayed, or scuttled releases. This proposal does not conflict with the burn-in process outlined here, and intends to build upon it. Both processes should be maintained, if accepted.
Call for an out of cycle release. RelCom has 24 hours to chime in. Once majority is obtained the release can proceed at the point majority is obtained. So Log4J has another CVE, Sally spins up a release PR, when eurpoe and amer wake up (possibly because their phones are going crazy) those relcom members give their vote. Once majority is reached release goes out. If it's a truly exceptional case a release can be done on an "ask for forgiveness" basis I expect. But to write those paths into a process is to invite abuse for drifting definitions of what meets the standard.
Perhaps we go the parlimentary route. Scheduled releases are to be done "without objection" and if one party formally objects then a formal vote is required of the RC. At least 24 hours is required for a vote to close, and a scheduled release can be delayed for the vote.
...
combine it with the friday "commit pick" and everyone has 3-4 days (2 business days) to find a reason to object.
I think we would need to write in that a maintainer or RC member raises the objection, so that random trolls can't force votes. And the objection comes in besu-release or 'the agreed communication channels'
Like an apache PMC, project management committee. Their job is to approve releases and update their own membership.
...