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 routeOff-cycle, Delayed, and Scuttled releases are defined as any release altered from its date on the release schedule by more than 24 hours, either pulled forward to address a critical bug or patch, delayed to accommodate bugs or issues exposed during the release (n-5) burn-in period, or something extenuating to require scuttling the entire release.
A release committee would be established to make go/no-go decisions on moving releases. This committee is comprised of Maintainers to begin with, but can be expanded to include non-maintainers as the contributor base grows. Only committee members can raise votes. Scheduled releases are to be done "without objection" and if one party formally objects then a formal vote is required of the RCcommittee. At least 24 hours is required for a vote to close, and a scheduled release can be delayed for the vote.
If we have to vote every two weeks there will be RC fatigue and the RC wont' be able to discern easily what a real exception looks like.
combine it with the friday "commit pick" and everyone has #besu-release in Discord is the intended venue for this vote and discussion. If RC members cannot be reached within the 24 hour period, their vote must be delegated. If that Maintainer is unreliable for multiple votes, they may be removed from the committee.
With the combination of the Friday "commit pick" for the burn in process, Maintainers and RC members will have 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.
Apache has also dealt with these specific problems before, so taking heed to their process that was formed from this same scar tissues seems warranted.
Also, consider that Ethereum Mainnet is not the only vested interest in this projects, Hedera, Etehreum Classic, and several enterprise chains have needs that may conflict with the desire to scuttle a release because attestations went down one tenth of a percent.
They may not, and may be ok with scuttling, but they may require a pending PR that is in conflict with a performance regression of a component they don't use.a regularly scheduled release and 24 hours to vote. A release can be delayed with majority rule from RC members.