+1 from the sidelines. I don’t understand >>>* 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. <<< Who is forced to do anything and for what reason?
AFAIK cascading dependencies can be handled by releasing cause + all effects at once. If that’s hard to do now, maybe there’s a way to make it easier. I’d expect it would make testing a change more plausible as well. David Jencks > On Nov 18, 2022, at 10:44 AM, Romain Manni-Bucau <rmannibu...@gmail.com> > wrote: > > 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 <ta...@cservenak.net> 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 >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
