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
