> 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] > >
