> On Sep 3, 2026, at 9:40 AM, Xuanwo <[email protected]> wrote:
>
> I support the concurrent votes as a way to speed up the release process for
> incubator projects.
>
> Based on my experience with incubator projects, it's much better to be
> rejected on the first day by the IPMC than to pass the PPMC's vote and then
> wait three days only to have the release rejected by the IPMC. Concurrent
> voting also allows the IPMC to participate earlier in the release process.
I would like to recommend that podlings try a release using Apache Trusted
Releases Beta at https://releases.apache.org/. This system will check for many
of the problems that are found in a release vote prior to starting the release
process. The release manager can replace packages until the checks pass.
ATR currently does sequential voting periods, but if the IPMC approves the
concurrent option then we can make changes to enable it as a configuration
choice.
Best,
Dave
>
> On Fri, Sep 4, 2026, at 00:22, tison wrote:
>> The following comments are integrated:
>>
>> 1. (David & Justin; change the order)
>>> The PPMC vote and the Incubator PMC vote MAY be conducted sequentially or,
>> at the Podling's discretion, concurrently.
>>
>> 2. (Dave; individuals in both groups)
>>> The individuals counted toward these two requirements need not be
>> distinct. An individual who is both a PPMC member and an Incubator PMC
>> member, including a Podling mentor, may be counted toward both requirements.
>>>
>>> Only votes from Incubator PMC members are binding for ASF release
>> approval.
>>
>>> With concurrent votes, the IPMC ends up reviewing RCs the PPMC would have
>> rejected anyway, and IPMC time is the one thing we're short of.
>>
>> IPMC members can choose to review only releases that have a PPMC vote
>> result. It's up to certain IPMC members' preferences.
>>
>> From another viewpoint, Fesod and Seata may identify those issues earlier
>> with the help of an IPMC member, shortening their total release time.
>>
>> Best,
>> tison.
>>
>>
>> Justin Mclean <[email protected]> 于2026年9月4日周五 00:09写道：
>>
>>> Hi,
>>>
>>> I'm not against concurrent votes, but I've one concern and a few wording
>>> changes.
>>>
>>> The concern is that this puts more work on the IPMC. At the moment, the
>>> PPMC vote filters out RCs with issues before they reach general@. With
>>> concurrent votes, the IPMC ends up reviewing RCs the PPMC would have
>>> rejected anyway, and IPMC time is the one thing we're short of. That on its
>>> own may be reason enough not to do this.
>>>
>>> If we do go ahead, both votes will still run for 72 hours, and both will
>>> be closed with a result before anything is published.
>>>
>>> The general@ vote email should still link to the dev@ vote thread so IPMC
>>> members can see it and check the tally.
>>>
>>> I'd put sequential first and say it's the default. Concurrent should be
>>> something a podling chooses, as an exception, not the expectation.
>>>
>>> Note this changes pages/policy/incubation.ad, which is Incubator policy,
>>> so it needs an IPMC vote to adopt once the wording is settled.
>>>
>>> Regarding JB's suggestion of sending one thread to both lists, I'd rather
>>> not. Replies end up on one list or the other, and the tally gets messy. Two
>>> threads running at the same time give the same result without that.
>>>
>>> Thanks,
>>> Justin
>
> --
> Xuanwo
>
> https://xuanwo.io/
>
> ---------------------------------------------------------------------
> 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]
