Hi Justin, Thanks for your feedback.
I agree with your points and would withdraw the proposal about the fast path proposed here. For simultaneous releases, check out [1][2] for discussion. [1] https://lists.apache.org/thread/1jjbb1yjqngc87g9ocwwnsgbrn93x0xb [2] https://github.com/apache/incubator/pull/145 For expedited votes in Incubator, it can be a separate discussion thread. I may start one once we have consensus on simultaneous releases, so that we don't mix up different but relevant topics. This helps other IPMC members to follow the discussion. Best, tison. Justin Mclean <[email protected]> 于2026年9月3日周四 23:56写道： > 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
