Hi Julian, > I suggest the following compromise: The release manager can start an IPMC vote thread as soon as there are at least 3 votes on the PPMC thread. Both votes must run for at least 72 hours, as usual.
This is better than a strictly sequential process, so I'm glad to see it happening. My feedback here is that it creates a new type of "restriction" on releases, while my primary tendency in the Incubator is to run Podlings as if they are TLP, only plus that it is under IPMC's oversight and an IPMC vote bridges PPMC's releases as TLP releases. So, as JB wrote: > it would be closer to what a project does post graduation I still hope that a podling gets the impression that a release is concluded by majority approval [1]. The IPMC vote performs this, and the PPMC vote mimics this. No other restrictions. [1] https://www.apache.org/foundation/voting.html#ReleaseVotes Best, tison. Julian Hyde <[email protected]> 于2026年9月4日周五 09:05写道： > I suggest the following compromise: The release manager can start an IPMC > vote thread as soon as there are at least 3 votes on the PPMC thread. Both > votes must run for at least 72 hours, as usual. > > This addresses Justin’s concern that the IPMC will end up doing most of > the work. But it also allows a podling to “fail fast”, and iterate release > candidates in 3 days or less. > > By the way, I am grateful to Tison for raising this issue. The perception > that the ASF is tied up in red tape hurts us. It is longstanding, it is not > wrong, and it starts in the Incubator. I know of several projects that have > chosen to go to the Linux Foundation or CNCF for this reason. I think most > of us do. So let’s fix it. > > To solve this issue, we will need to make some compromises. I would like > to see this discussion ending in a vote — if necessary more than one — > where IPMC members put their opinions on record. > > Julian > > > > On Sep 3, 2026, at 5:09 PM, Justin Mclean <[email protected]> > wrote: > > > > Hi, > > > > ATR is useful but it won't change much here. It checks signatures, > hashes, headers, and the presence of the DISCLAIMER, and those rarely get a > -1. The analysis of ten years of general@ release votes [1] found the > mechanical issues have mostly gone. Releases get voted down on general@ > for things that need a person to look at: bundled third-party code with no > license, LICENSE and NOTICE that don't match what's in the archive, > category X dependencies, compiled code in the source release, etc. Tooling > won't find those sorts of issues. > > > > Concurrent votes don't reduce that review, they just mean the IPMC does > it on RCs the podling hasn't checked yet. If IPMC members wait for the PPMC > result before looking, as Tison suggests, then the general@ vote sits > idle until it arrives. > > > > Thanks, > > Justin > > > > 1. > https://cwiki.apache.org/confluence/spaces/INCUBATOR/pages/393677685/Release+Vote+Insights > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
