You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

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.

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 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.

  • No labels