HI, -1 from me.
You're right that 3 IPMC +1s over 72 hours satisfies the release policy on paper, so my objection isn't about the number of votes. The 72 hours is there so everyone on the PMC has a chance to take part in the decision to release. For a podling, the PMC is the IPMC, and the IPMC takes part on general@, not on a podling dev list that most of the IPMC doesn't read. So 3 IPMC members voting on dev@ doesn't mean the IPMC has approved the release. A release is an act of the Foundation, and that comes from the IPMC vote. It's what the legal protection for release managers and PMC members is based on. The release policy says that deviating from it may weaken that protection and affect the Foundation's insurance, and that it requires board approval first. Any change to release policy would also need VP Legal approval. Reviewing after the release also assumes you can pull it if something is wrong, and you can't. Maven Central doesn't remove artefacts, crates.io only yanks, PyPI and npm burn the version. Whatever is wrong is out there under the Apache name for good. The general@ vote is where people other than the mentors look at the release, and that's where most issues get found. I also don't think the data supports it. Of the last nine podling releases on general@, only three had 3 or more IPMC votes on dev@. The two with none, Fesod and Seata, were the two where issues were found on general@. Where podlings do wait, it's usually for a second or third IPMC vote because mentors haven’t voted, and that's a mentoring problem, not a policy one. Running the two votes in parallel is a different thing, and that may be worth considering, as long as both run for 72 hours and the PPMC vote is closed with a result before anything is published. The Incubator release policy would need to be revised to allow it. If a release really does need to be quick, say for a known security issue, the expedited release process already applies to podlings. Both votes can be shorter and the vote email needs to say why, and the board needs to be notified, usually in the next Incubator report or earlier if it's urgent. That's for exceptional cases only. Something similar came up in 2019 [1], where the idea was for mentors to vote on dev@ and close on general@ 72 hours later if nobody objected. What we do now, carrying IPMC votes from dev@ and still running the general@ vote for 72 hours, is more or less where that ended up. Kind regards, Justin [1] https://lists.apache.org/thread/g8k7xbgpqtxm5cfl919r72s2xm43drmq
