Skip to end of metadata
Go to start of metadata

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

Compare with Current View Page History

« Previous Version 5 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. 


Off-cycle, Delayed, and Scuttled releases are defined as any release altered from its date on the release schedule by more than 24 hours (to accommodate contributor time-zones), 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 committee. At least 24 hours is required for a vote to close, and a scheduled release can be delayed for the vote. #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 to a regularly scheduled release and 24 hours to vote. A release can be delayed with majority rule from RC members. 

  • No labels