> The PPMC has 3 +1 votes together -> sends notice to the IPMC lists and if there is no objection the release goes out.
I wrote "if the PPMC votes already have 3 +1 votes from IPMC members". Note the "+1 votes from IPMC members" part. So the fast path proposal is basically: shall an IPMC vote get IPMC members' votes from [email protected] and require a 72-hour time window? Carrying votes from dev@ to general@ should be easy, but we can only wait another 72 hours to pass. Best, tison. Christofer Dutz <[email protected]> 于2026年9月3日周四 17:09写道： > I read your proposal: > > The PPMC has 3 +1 votes together -> sends notice to the IPMC lists and if > there is no objection the release goes out. > That would have broken that fundamental rule. > > Chris > > Von: tison <[email protected]> > Datum: Donnerstag, 3. September 2026 um 10:56 > An: [email protected] <[email protected]> > Betreff: Re: [DISCUSS] Fast path for IPMC vote > > > I think 3 binding IPMC +1 votes is something non-negotiable … we can only > speed up the process to run in parallel. > > My proposal doesn't break this rule. > > However, I realize that I can start the IPMC vote now as the PPMC vote has > enough +1 votes so that we don't wait 72 hours for the "result" of PPMC > vote. > > Let me try and see. > > > Best, > tison. > > > Christofer Dutz <[email protected]> 于2026年9月3日周四 16:47写道： > > > Hi all, > > > > I would be in favor of an alternate plan (that has been mentioned) > > That if an expedited release is necessary, that the IPMC vote can be > > started after receiving 3 +1 votes. > > This way the IPMC votes are not the votes that get the release above the > 3 > > +1 threshold. > > > > Your suggestion with the Notice would break one fundamental Apache rule: > > A release has to be an act of the foundation. > > > > If we’d release based on a notice email, we would be breaking that rule. > > > > I think 3 binding IPMC +1 votes is something non-negotiable … we can only > > speed up the process to run in parallel. > > > > At least this is how I see it. > > > > Chris > > > > > > > > > > Von: tison <[email protected]> > > Datum: Donnerstag, 3. September 2026 um 07:54 > > An: [email protected] <[email protected]> > > Betreff: Re: [DISCUSS] Fast path for IPMC vote > > > > Let me bring some background to make the discussion more concrete > > rather than directing it to the policy abstractly. > > > > The first ASF release of Asyncband gets 6 +1 binding votes in the PPMC > > vote [1], while 4 +1 votes come from IPMC members. It happened on the > > first day, and I need to wait for five extra days just to follow the > > policy. > > > > [1] https://lists.apache.org/thread/stmtcjsgpzt2vl8mlklf5zovbp9o4nr7 > > > > Maybe this happens only for the first release or only when the project > > is in the rapid development stage. But it strengthens the impression > > that ASF may slow down your releases. > > > > Maybe I should conclude an expedited release here and not modify the > > policy or seek a fast path. > > > > I found it less than awesome and am trying to find an improved way. > > > > Best, > > tison. > > > > tison <[email protected]> 于2026年9月3日周四 13:47写道： > > > > > > > I am also not entirely in favour of the proposal where, once the PPMC > > > > has three +1 votes on dev@, the release can proceed with only a > notice > > > > to general@. Instead, in such extraordinary circumstances, perhaps > the > > > > vote could be run concurrently on both dev@ and general@. This would > > > > still allow everyone who is entitled to vote to participate, while > > > > reducing the overall time required. > > > > > > So I emphasize, only the PPMC vote gets 3 IPMC votes can it follow this > > path. > > > > > > Simultaneously releasing would break the assumption that the Incubator > > > wants the PPMC to first check their own release rather than push the > > > check to IPMC for the first time. Delima here. > > > > > > Best, > > > tison. > > > > > > tison <[email protected]> 于2026年9月3日周四 13:44写道： > > > > > > > > > Otherwise, 72 × 2 hours = 6 days does not seem excessively long for > > getting a release out after an RC. > > > > > > > > This is the tricky part. > > > > > > > > For an open-source distributed system that typically releases > > > > quarterly, it won't be an issue. For a dormant library that even > > > > releases yearly, it won't be an issue. > > > > > > > > But for an early-stage project that would develop rapidly, as you may > > > > know, many projects release multiple times in one day or in one week. > > > > It starts to be an issue. > > > > > > > > This is tricky because projects vary among our foundation, so one > > > > policy for all of them may cause a bad experience for certain > > > > projects. > > > > > > > > Best, > > > > tison. > > > > > > > > Ayush Saxena <[email protected]> 于2026年9月3日周四 13:36写道： > > > > > > > > > > > > > > Hi tison, > > > > > For TLPs, there is already a process for an expedited release [1], > > > > > which I believe can also be used for podlings. This could help > reduce > > > > > the duration of the vote when there is a genuine need to get a > > release > > > > > out quickly. > > > > > I believe FastTrack should be reserved for genuinely critical > cases. > > > > > Otherwise, 72 × 2 hours = 6 days does not seem excessively long for > > > > > getting a release out after an RC. In fact, many projects generally > > > > > run their release votes for around a week. > > > > > > > > > > I am also not entirely in favour of the proposal where, once the > PPMC > > > > > has three +1 votes on dev@, the release can proceed with only a > > notice > > > > > to general@. Instead, in such extraordinary circumstances, perhaps > > the > > > > > vote could be run concurrently on both dev@ and general@. This > would > > > > > still allow everyone who is entitled to vote to participate, while > > > > > reducing the overall time required. > > > > > > > > > > That said, I would still prefer this mechanism to be limited to > > > > > exceptional circumstances where an expedited release is actually > > > > > warranted, similar to the existing expedited release process for > > TLPs. > > > > > > > > > > -Ayush > > > > > > > > > > [1] > > https://www.apache.org/legal/release-policy.html#expedited-releases > > > > > > > > > > On Thu, 3 Sept 2026 at 10:53, tison <[email protected]> wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > Currently, for a typical podling release, one should go through a > > PPMC > > > > > > vote + an IPMC vote, both with a minimum of a 72-hour period > > [1][2]. > > > > > > > > > > > > [1] > > https://www.apache.org/legal/release-policy.html#release-approval > > > > > > [2] https://incubator.apache.org/policy/incubation.html#releases > > > > > > > > > > > > IIRC, there are several discussions about release velocity. Here, > > I'd > > > > > > like to propose a concrete fast path for an IPMC vote to reduce > the > > > > > > reputation of "the ASF (Incubator) will slow your project." > > > > > > > > > > > > That is, if the PPMC votes already have 3 +1 votes from IPMC > > members, > > > > > > with a notice to [email protected] for further (post) > review, > > a > > > > > > podling can conclude the release. > > > > > > > > > > > > I'd like to hear your feedback. Or perhaps a podling that keeps > > > > > > releasing and evolving well should just consider graduating from > > the > > > > > > Incubator. > > > > > > > > > > > > Best, > > > > > > tison. > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > 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] > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > >
