To follw up on why I think this is a worth while to adopt:
It essentially comes down to attempting to reduce the workload and effort on
the release manager (which is already a pretty hidden and in someways thankless
job!)
When we discover a last minute bug like we did here it's quite stressful for us
as RMs, because it means another three days elapsed time with the release
"hanging over" our heads, with no guarnatee that it won't happen again right at
the end of the vote next time. (My mind goes back to the 1.9.0 release where we
made it to an RC8! Thankfully we've gotten a lot lot better since then. Read:
automated more)
By adopting this sort of policy it will mean that we can more easily fix things
discovered during the release process and have higher quality .0 releases (the
last.. 2? 3? minor releases have all needed a .1 follow up almost straight away
afterwards)
So by allowing shorter follow-on votes we can fix things quicker and hopefully
as a result we end up publishing higher-quality releases.
One option on the a) b) questions might be to allow short vote for the next two
releases, and then examine if it helped or not once 2.6 is out (the next
release).
On Nov 30 2022, at 9:57 am, Ephraim Anierobi <[email protected]> wrote:
> +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
> >``is
>
