> On Sep 3, 2026, at 11:18 AM, Julian Hyde <[email protected]> wrote:
>
> Dave,
>
> Are there any public resources describing ATR? ATR sounds interesting, but
> the link you sent requires me to log in with my Apache ID and 2FA. I have not
> taken the time to set up 2FA, and some of our readers may not have an Apache
> ID.
These pages are open:
1. https://releases.apache.org/docs/ - this is a work in progress.
2. https://tooling.apache.org/trusted-releases.html - this is an overview of
what to configure to start.
We will be at C/C Glasgow with an ATR session and workshop on Monday and a
Tooling hackathon Tuesday morning for onboarding PMCs and working on Docs.
Best,
Dave
>
> Julian
>
>
>> On Sep 3, 2026, at 10:59 AM, Dave Fisher <[email protected]> wrote:
>>
>>
>>
>>> 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]
>>
>
>
> ---------------------------------------------------------------------
> 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]
