You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tooling.apache.org by Dave Fisher <wa...@apache.org> on 2026/08/01 15:13:37 UTC
Re: Recommendations about announcing votes through ATR
> On Jul 31, 2026, at 4:05 PM, sebb <se...@gmail.com> wrote:
>
> On Fri, 31 Jul 2026 at 22:40, Dave Fisher <wa...@apache.org> wrote:
>>
>>
>>
>>> On Jul 31, 2026, at 1:03 PM, Jarek Potiuk <ja...@potiuk.com> wrote:
>>>
>>> Thanks Sean. I'll take a look at that page - but I would actually prefer
>>> Sebb to handle it.
>>>
>>> He is the most likely person who might raise similar complaints and did in
>>> the past.
>>>
>>> Sebb - can you please confirm that this is enough for you to **not** raise
>>> complaints in case we use ATR in the future following the page. I would
>>> really appreciate it - and ATR team for sure - this would allow those who
>>> afraid to use ATR because they fear being told they are doing it wrong to
>>> use it without hesitation.
>>>
>>> Generally - passing "Sebb's test" - blanket approving my future releases
>>> that I and my PMC will not be told "you are doing it wrong" is for me the
>>> condition of opting-in to ATR.
>>
>> A blanket approval for the future is an unreasonable request. There will be ways that you can do it wrong.
>>
>> Here are some hypotheticals.
>>
>> 1. Your VOTE email suggests downloading from SVN or GitHub Releases instead of or in addition to ATR. Since you control the VOTE email template you can make a mistake. A mistake can be corrected without restarting the VOTE.
>> 2. You could simply be making a mistake.
>> 3. In both Legacy and ATR releases you fail to mention the download page in your release announcement. The announce@apache.org mailing list is moderated by Sebb and others. It is their job to reject invalid announcements.
>
> Not any more; announce@ moderation was taken over by M&P.
> You would need to ask them what criteria are used now.
Thanks for letting me know I’ve raised https://github.com/apache/tooling-trusted-releases/issues/1480 for the team to check with M&P.
>
>> You, your PMC, and the Release Manager need to decide if a Sebb (or anyone else’s) -1 is binding and blocking in any way. You can ignore his complaint. He can submit the issue in other ways, if there is a need to escalate.
>>
>> Best,
>> Dave
>>
>>> Even if Sebb has no formal position - he is the one that I simply DREAD to
>>> come at my release and say "you are doing it wrong". So ....
>>>
>>> Sebb, I think you now have the task of being able to be used by other
>>> PMCs—saying "yes" will release the testing. Say "no" - and point out what's
>>> wrong and you will hold it back.
>>>
>>> If you say nothing, you leave it in a limbo state, which is neither good
>>> nor bad.
>>>
>>> Everything now depends on you.
>>>
>>>
>>>
>>> J.
>>>
>>> On Fri, Jul 31, 2026 at 9:22 PM Sean Palmer <sb...@apache.org> wrote:
>>>
>>>> Hi Jarek,
>>>>
>>>> In addition to what Dave said, I forgot to tell you earlier that I had
>>>> also added a page to ATR which can be used for this purpose. The URL
>>>> is:
>>>>
>>>> https://release-test.apache.org/docs/staging-and-voting
>>>>
>>>> And it contains the following wording:
>>>>
>>>> "ASF release policy accommodates this. The policy recommends that
>>>> projects use either the dist/dev tree or the staging features of
>>>> repository.apache.org to host release candidates, and it describes
>>>> dist/dev as a staging location intended for use before a release
>>>> becomes official. That recommendation does not preclude other staging
>>>> locations, and the policy does not require any particular one. ATR is
>>>> a further place where candidates may be staged."
>>>>
>>>> If anything on this page needs to be improved in any way, please let us
>>>> know.
>>>>
>>>> --
>>>> Sean B. Palmer
>>>> ASF Tooling
>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
>> For additional commands, e-mail: dev-help@tooling.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
> For additional commands, e-mail: dev-help@tooling.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For additional commands, e-mail: dev-help@tooling.apache.org