Re: [VOTE] Release Manager Selection
| From: | Daniel Scherzer | Date: | Mon, 25 May 2026 19:16:44 +0000 |
| Subject: | Re: [VOTE] Release Manager Selection | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-131013@lists.php.net to get a copy of this message | ||
On Mon, May 25, 2026 at 12:10 PM Derick Rethans <derick@php.net> wrote:
> On Mon, 18 May 2026, Tim Düsterhus wrote:
>
> > I just opened voting for the “Release Manager Selection” policy RFC.
> >
> > The RFC text is in:
> > https://wiki.php.net/rfc/release_manager_selection_policy
> > The PR with
> > the actual policy is:
> > https://github.com/php/policies/pull/28 The
> > discussion thread is: https://news-web.php.net/php.internals/130470ÌñŠd
> > Áôz)é31U
> >
> > Voting runs until 2026-06-01 12:00:00 UTC. There is a single primary
> > vote to cast.
>
> I voted no on this. Not because of the policies themselves, but because
> "hands-off" and "hands-on" are phrases from a school yard — and
> suggestions to come up with better names were ignored.
>
> cheers,
> Derick
>
>
^^^This - I voted no for the same reason. If the RFC passes, I plan to
write up a follow-up to change the terms.
After discussion with some other release managers and developers at PHPTek,
I haven't heard any arguments *against" the terms "Veteran release manager"
and "Co-release managers". Those terms would also makes it clear that
* the veteran need not be "hands-off", that can be decided by the RM team
* the veteran is clearly a veteran (from the name) rather than just someone
who doesn't do much ("hands-off") and you have to check the policy to
understand why
* the veteran is still involved in things, even if they are not making the
actual releases
-Daniel