> shall an IPMC vote get IPMC members' votes from [email protected] and require a 72-hour time window?
... or if we _can_ run simultaneous votes on both dev@ and general@; then it should be fine or better than the current situation. Best, tison. tison <[email protected]> 于2026年9月3日周四 17:12写道： > > 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] >> > >> > >> >
