Howdy, I think you got it a bit "upside down": it is not a project that "cares" for people (this is not a corp), it is the other way around. As for key people, they should be "key" for a reason, I trust they care, so I am pretty much sure "key people" will be present when needed (they usually are). On the other hand, if a PMC member decides to take a bus tour and crashes, the fact he lies in a hospital (in gypsum with hanging limbs, like in cartoons) does not mean he doesn't care, as he will not vote even after 72h (replace here child birth, hangover after a too successful party, or whatever). And again, unsure what 3 days matter. Release process is already HOURS (just sync is 2+), so let's make it AT LEAST 72h? It should be a push of a button.
But I think I described where 72h does matter, in my 1st mail. The answer to "it is a good thing to enable people to review a release and have the opportunity to give feedback" is among canned responses :) T On Fri, Nov 18, 2022 at 7:44 PM Romain Manni-Bucau <[email protected]> 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 <[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 > > >
