+1 to both (a) and (b) since RC2 up is usually a few commits
On 2022/11/30 09:47:26 Ash Berlin-Taylor wrote: > Hi All, > > We've just had a case where a 11th hour bug on 2.5.0rc2 (well technically, > 12:01 as the vote time had finished, but we hadn't closed it yet/wouldn't > have released anyway) https://github.com/apache/airflow/issues/28002. > The fix is easy (it's a two line change, plus a bit of tidy up) but we have > to prepare a new RC and have a new vote on it. The "annoyance" is that we > currently have a 72 hour vote window. > The reason for a long vote window is to give people in various time zones the > chance to engage which makes sense, espeically in the case of a big release > where there might be a lot to test or look over. But I think in the case of > follow up RCs where the changes should only ever be small on top of the the > already voted-RC. > The ASF policies say: "Release votes SHOULD remain open for at least 72 > hours." Which means that we as a project can change it if we decide it is > appropriate. > To be more concrete about what I propose we adopt: > Voting periods for subsequent RCs (i.e. RC2 and above) of a release can be > reduced to be 72 hours since the start of the vote for RC1. The requirements > for 3 new binding votes remains. This should only be used when the difference > between the RCs is small (as judged by the release manager) > To give an example: > In this case (2.5.0rc2 vote), if we cancelled the vote and had an RC3, since > the 72hour voting period has already elapsed the vote for RC3 would only run > until the three binding votes are recieved. > or another case; > If we cancel a vote for RC1 after 24 hours, then the vote for RC2 would only > need to run for 48hours, rather than the "usual" 72. > This is important enough that I think it needs a vote, and shouldn't be > something we use lazy consensus to achive. > So the questions: > a) Do you think this is a policy we should formally adopt? > b) Can we use this for the about-to-be-voted on 2.5.0rc3? > > -ash >
