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
