> 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.
