Hi Tamás, Is 3 days that bothering - didnt spot it to be honest? Indeed, strictly speaking you can do "until we get 3 bindings +1" - don't think you can say for a maximum otherwise it means you need to cancel if you don't get it ;) - but it also means you mean the project does not care about its core people - if you start the release on friday night you potentially let 0s to some PMC and users to review the release. Indeed it is ont an apache requirement but I think it is a good thing to enable people to review a release and have the opportunity to give feedback so 3 days sounds like a very good default if you take into account the world side - timezones - of our project.
Side note: guess exceptions can be done for CVE, milestones, beta, alpha, ... - anything not final or urgent but very located. Hope it makes sense. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le ven. 18 nov. 2022 à 18:55, Tamás Cservenák <[email protected]> a écrit : > Howdy, > > My pet peeve these days is our release process. IMHO, we should be able to > release ("move") much faster than today. > > My proposal would be: > * vote is "done done" the moment quorum is reached > * change the wording in the vote email from "Vote open for at least 72 > hours." to "Vote open for a maximum of 72 hours.". > > Reasoning: > * vote cannot be vetoed by definition (only release mgr can cancel it). > * change would not conflict with ASF defined rules, the 72h is not > compulsory (document states "should" not "must"). > * the release process is already wearisome, complex, and is easy to miss > (over-represented) manual steps. For example yesterday for some reason it > took almost 2 hours to sync release artifacts to Maven Central, during > which you are in a "busy loop" (the announcement and site depends on sync). > Leaving it "for tomorrow" may cause users to learn about a new release thru > Artifact Listener or whatever other service, causing confusion. Ideally, > site and announcement mail should be tied to sync, and that does lead to > "busy loop". > * current process causes (forced) context switching, and can likely lead to > human mistakes: when the release vote is announced, developer is FORCED to > stop for 72h and possibly switch. This is just a productivity killer. > * which part do you like: as a developer sitting on needles while being > blocked on upstream (dependency) bugfix or as a user waiting for bugfix? > * we already agreed on one minor process improvement: we have quite long > "chains" of dependencies, so a bugfix that can span on long trails could > take weeks to be done serially, even if the bugfix itself is trivial. Hence > we did accept that we can do "batch votes" (release together) and can do > one vote for this case. > * on positive site this could lead to mindset change of bugfix releases, as > today, few wants to go thru painful release process for "single simple > change" (see ASF Slack #maven for "ahh Apache process..."), that IMHO is > wrong: we all should release early and often. And be happy with it, not > feel it like chores :) > > Finally some "canned responses": > * "time is needed for all interested parties to review": If someone cannot > get to it in 5 minutes, or in 5 hours or in 5 days, it really but really > does not matter, as release is to happen anyway (unless release mgr cancels > it). One not getting to it, will be notified via mails anyway (vote, > result, announce). We can already observe that there are "areas of > interests", but also there is the customary habit of "review invitation" > which is a good thing IMHO, as usually one invites a colleague with whom > the topic was or is under discussion already, so both of them are > "contextualized". Those initiated developers will most probably join in > voting for release as well, as either they depend on the fix or they know > what the problem was. > * "this will lead to more bugs" or "we are too hasty making changes": no, > it will not and we are not. As in essence, this change would allow us, in > case of need, to release even multiple times per day (so release the > project carrying a bug in the morning, then have a patch release for it in > the afternoon). Really, as bugs are inevitable, they happen with or without > 72 hours, still the current process just causes problems IMHO. As the new > release is sitting on Central, without immediate remediation possibility. > Or to put it another way, having this option open does not mean we will > make all releases like it, and we will not start competing by releasing all > the plugins several times a day :) You can see there are "hot spots'' (if > you look at maveniverse as whole, sometimes plugins, sometimes shared > stuff, sometime maven, etc), especially with closing releases of Maven, but > those hotspots come and go, move, and just like today, some components will > not be released for quite some time, as the hotspots move from here to > there. > > Applying this process change, if accepted, would not alter anything > regarding "commit policy" of code changes (PRs, JIRA attached patches, > etc). > > Refs: > https://www.apache.org/foundation/voting.html > https://www.apache.org/legal/release-policy.html > > Please comment, add your opinion. Ideally, if discussion closes with > "positive outcome", I would like to propose a vote for these changes. > > Thanks > T >
