Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130474
Precedence: list
MIME-Version: 1.0
Date: Sat, 28 Mar 2026 17:36:48 +0100
To: Ben Ramsey <ramsey@php.net>
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Release Manager Selection
In-Reply-To: <20260328063516.0050F1A00BD@lists.php.net>
References: <093f97b0805b43ae640d80b9e06eb203@bastelstu.be>
 <20260328063516.0050F1A00BD@lists.php.net>
Message-ID: <77a050bd717117b9f2cc94d1f581197f@bastelstu.be>
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

Hi

Am 2026-03-28 07:35, schrieb Ben Ramsey:
> I think it's okay for someone to be an RM on up to 2 actively supported 
> versions of PHP at the same time.

I disagree and believe the limit for consecutive terms is very useful 
for the health of the project for several reasons:

1. It limits the the blast radius in case of a compromised release 
manager.

This includes both “compromised computer” and “stolen PGP key”, but of 
course also soft factors like “suitcase full of nice things”. When a 
release manager is guaranteed to be responsible for only a single 
release at a time, there is a much greater chance for the release 
manager of the other actively supported PHP version to notice “odd 
things” on release day, because they'll also be actively working on a 
release and thus touching the same repositories.

2. It makes it more likely to have a steady supply of new “rookies” from 
the community.

Without a limit on consecutive terms a veteran release manager could 
“step up” every year and if they were doing their job well, it would not 
be unlikely for them to be voted in every year. This would make it less 
likely for “rookies” to come in, who are more likely to question and as 
a result improve existing workflows - and also leave a hole when the 
veteran in question steps down for whatever reason.

3. RMs have the ultimate responsibility for a given release.

As an example, with the recent policy changes around the release process 
(https://wiki.php.net/rfc/release_cycle_update), any change after the 
soft-freeze needs to be approved by RMs. But even outside this explicit 
approval mechanism, RMs are responsible for the stability of the 
release. If any given feature cannot be sufficiently stabilized in time 
for the gold release, it might also be necessary for it to be reverted. 
These decisions are necessarily happening outside of the regular RFC and 
voting process and thus give the individuals who happen to be RM a 
greater control over the project than any other individual (core 
developer). While I'm positive that RMs will only act in the best 
interest of the PHP project - and so far have no evidence of the 
contrary -, there could be an incentive for an RM who performs their 
duty on company time to bend the rules in the interest of their 
employer. This also ties into (1) and (2).

For the above reasons, I think it is also useful for “separation of 
powers” if an active core developer is not also an active release 
manager (and of course also because the time of someone who can work on 
php-src is more usefully invested in doing the actual development). 
That's why I'm personally not applying to be RM.

Best regards
Tim Düsterhus