I agree that having to wait another 72 hours can be a little annoying. I like Jarek idea of an incompressible 24h window if the previous RC was close to an end. This feels like a good compromise and also leave people some time to do further testing in case the highlighted bug is tied to other issues/PRs. (Or if the fix requires further testing).
That being said I totally understand that having to wait represents extra work for the RM, and I wouldn’t mind a shorter window as Ash suggested. On Wed 30 Nov 2022 at 17:56, Damian Shaw <[email protected]> wrote: > > It is tempting to speed it up, more, but we've been already called out > by the ASF board by rushing a release when it was not really justified > (when we released 1.10.8 > > FYI if a similar situation happens with a future release of Airflow is > that pip fully respects yanking now, compared to when 1.10.7 and 1.10.8 > were released. > > So if a release is made and it turns out to immediately be broken it would > be possible to mark it as yanked on pypi and users who are on pip 22.0 or > higher won't have a yanked release from either "pip install > apache-airflow" nor if airflow is a transitive/dependency of another > project (unless the dependency exactly specifies [using == or ===] the > broken version of Airflow). > > -----Original Message----- > From: Jarek Potiuk <[email protected]> > Sent: Wednesday, November 30, 2022 6:31 AM > To: [email protected] > Subject: Re: [DISCUSS] Allow shorter voting periods for subsequent RCs > > Good point. The SHOULD is there and after discussions with the ASF folks > on JIRAs and [email protected] list - if there is a good reason, we can shorten > it. Critical security fix is definitely a good reason for it (happened in > Log4J for example) but the community (us) might decide on releasing it > earlier. > > This has also been a similar issue for Providers. I would even extend it > not only to RCs but also to "follow-up" releases when we discover bugs > "very quickly" after release. While we have quite a lot of testing by > contributors (as usual big thanks!), we have sometimes cases (like with > this wave in November) that we had quite a big common.sql refactor and some > errors were found **just** after releasing them. > > And also in case of providers, It's crucial in such cases that fixes are > released **just** before releasing Airflow and generating constraints. > There is no need to have "sequential" voting - it should be perfectly safe > to release providers, regenerate constraints and release Airflow right > after. > > So on top of this issue described by Ash, I think we should make a little > - non-blocking but considered - dependency: (fixing buggy) Providers -> > Airflow (and also speed up Provider's release in cases like that that we > found rather serious - but easy to fix - problem just before releasing > Airflow - (they are rare cases, but happened already few times when it > would be useful). > > I also think we should not **just** use RC1 timing. > > Especially when we are close or just about to finish the voting time, we > should give at least a few people a chance to test and review those > changes. I think we should give at least 24 hrs from releasing the new RC > to allow that (unless we have REALLY good reason - i.e. critical bugfix). > > It is tempting to speed it up, more, but we've been already called out by > the ASF board by rushing a release when it was not really justified (when > we released 1.10.8 > https://airflow.apache.org/announcements/#feb-7-2020 because of Werkzeug > release breaking our release thread here: > https://lists.apache.org/thread/f4ktxwqpy25olbspgncsh2lg3oqq4gfv. > Shorter vote thread here: > https://lists.apache.org/thread/5wp2zfx5qs5rr8ggct341bx398qj8v5z > > I vaguely remember (but unfortunately cannot find it easily, quickly - > maybe others will) the Apache Board complained that the decision was not > really justified back then to do it "immediately" because there was no need > for immediacy. > > Summarizing: I am all for speeding up follow-up releases, but I think we > should also leave some (much shorter) room/time for voting - at least > giving a chance someone who is sleeping to raise some concern: > > So my proposal: > > 1) Yep. let's shorten it > 2) But, if there are less than 24 hrs left let's leave at least 24 hrs > 3) Let's apply it also to bugfix release providers (when they might fix a > buggy provider just before the release). > > And if we are ok with that - and yeah - if this is 24hrs, we could apply > it for current release and ask for lazy consensus in parallel for this > policy. I think 24hr should be enough for lazy consensus and voting on > release running in parallel. > > > > J. > > On Wed, Nov 30, 2022 at 11:23 AM Ash Berlin-Taylor <[email protected]> wrote: > > > > 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 > ________________________________ > Strike Technologies, LLC (“Strike”) is part of the GTS family of > companies. Strike is a technology solutions provider, and is not a broker > or dealer and does not transact any securities related business directly > whatsoever. This communication is the property of Strike and its > affiliates, and does not constitute an offer to sell or the solicitation of > an offer to buy any security in any jurisdiction. It is intended only for > the person to whom it is addressed and may contain information that is > privileged, confidential, or otherwise protected from disclosure. > Distribution or copying of this communication, or the information contained > herein, by anyone other than the intended recipient is prohibited. If you > have received this communication in error, please immediately notify Strike > at [email protected], and delete and destroy any copies hereof. > ________________________________ > > CONFIDENTIALITY / PRIVILEGE NOTICE: This transmission and any attachments > are intended solely for the addressee. This transmission is covered by the > Electronic Communications Privacy Act, 18 U.S.C ''2510-2521. The > information contained in this transmission is confidential in nature and > protected from further use or disclosure under U.S. Pub. L. 106-102, 113 > U.S. Stat. 1338 (1999), and may be subject to attorney-client or other > legal privilege. Your use or disclosure of this information for any purpose > other than that intended by its transmittal is strictly prohibited, and may > subject you to fines and/or penalties under federal and state law. If you > are not the intended recipient of this transmission, please DESTROY ALL > COPIES RECEIVED and confirm destruction to the sender via return > transmittal. >
