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]
