Hi
please find the following RFC that is intended to clarify the “Release Manager Selection” policy for future PHP versions:
It is written in response to this email in the PHP 8.6 RM selection thread that pointed out possible ambiguity with regard to who is allowed to apply as a RM and as to how to interpret the results of the vote: php.internals: Re: Release Managers for PHP 8.6
Best regards
Tim Düsterhus
On 3/27/26 13:15, Tim Düsterhus wrote:
Hi
please find the following RFC that is intended to clarify the “Release Manager Selection” policy for future PHP versions:
PHP: rfc:release_manager_selection_policy
It is written in response to this email in the PHP 8.6 RM selection thread that pointed out possible ambiguity with regard to who is allowed to apply as a RM and as to how to interpret the results of the vote: php.internals: Re: Release Managers for PHP 8.6
Best regards
Tim Düsterhus
I'm not sure I like the notion or language of "hands-off" vs. "hands-on" release managers. What we've effectively practiced since at least PHP 8.1 is this:
1. At least 3 RMs per release
2. At least 1 of the RMs MUST be a veteran to advise the others
3. At least 2 of the RMs MUST be active during their tenure
The RMs themselves decide how they want to organize their schedules. I don't think the policy needs to be much more rigid than this.
It's okay for more than 1 RM to be a veteran, provided at least one of the 3 RMs is a veteran.
I think it's okay for someone to be an RM on up to 2 actively supported versions of PHP at the same time. They'll need to work together with their fellow RMs to ensure their duties are adequately covered, but I disagree with designating whether anyone is "hands-on" or "hands-off."
Cheers,
Ben
Hi Tim,
Thank you for this RFC. Though I do have some concerns towards the new direction.
What was the initial idea to split between rookies and veterans?
As a candidate for 8.6 it feels as a chance/opportunity to get more involved, and to build up experience as a RM (and more) as opposed to a veteran who already had the opportunity to do so.
With the new policy it would essentially allow only veterans to be RM with 2 hands-on and 1 hands-off and perhaps include more favoritism to a more experienced RM rather than someone with a clean record. The terminology of rookie lowers the bar a little to allow this in my opinion.
The veteran is there to advise the others. I don’t see why this needs to be hands-off. As long as there are always 2 hands-on available. So to that I am in favour of Ben’s wording.
On Mar 27, 2026 at 19:17 +0100, Tim Düsterhus tim@bastelstu.be, wrote:
Hi
please find the following RFC that is intended to clarify the “Release
Manager Selection” policy for future PHP versions:PHP: rfc:release_manager_selection_policy
It is written in response to this email in the PHP 8.6 RM selection
thread that pointed out possible ambiguity with regard to who is allowed
to apply as a RM and as to how to interpret the results of the vote:
php.internals: Re: Release Managers for PHP 8.6Best regards
Tim Düsterhus
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 (PHP: 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
Hi
Am 2026-03-28 11:56, schrieb Jordi Kroon:
What was the initial idea to split between rookies and veterans?
As a candidate for 8.6 it feels as a chance/opportunity to get more involved, and to build up experience as a RM (and more) as opposed to a veteran who already had the opportunity to do so.
With the new policy it would essentially allow only veterans to be RM with 2 hands-on and 1 hands-off and perhaps include more favoritism to a more experienced RM rather than someone with a clean record. The terminology of rookie lowers the bar a little to allow this in my opinion.
It is certainly not my intention to exclude “rookies” from the RM role. As I mentioned in my reply to Ben, the “term limit” in the policy explicitly exists to ensure that there won't be the same few folks every year. The policy just specifies a requirement of a veteran for the “off-hands” release manager, because they are only there for advice and backup purposes, which is a role that benefits from the veteran knowledge.
Given that this time we have two applications that would qualify as a veteran RM, I feel there is some ambiguity with setting up the vote that would not exist if folks would apply specifically for either “hands-on”, “hands-off” or “both”. As an example, did the veteran RMs only apply with the expectation that they would not be involved in the daily business (as was the case in the past few releases)? If more than one veteran would be voted in, would anyone of them want retract their application to “leave room” for a rookie? What if none of the veterans are amongst the first 3? With explicit “hands-on” and “hands-off” applications the “time investment” expectations are clear and it's also clear that it would be two separate votes, one selecting two “hands-on” release managers, one selecting a “hands-off” release manager (where only veterans may apply).
The veteran is there to advise the others. I don’t see why this needs to be hands-off. As long as there are always 2 hands-on available. So to that I am in favour of Ben’s wording.
If all three RMs would be actively involved in the release process, I would want all three of them to be blocked from becoming RM for another release for the reasons I mentioned in my reply to Ben. My observations of the past several releases were that there already effectively was a “hands on” and “hands off” split, with the rookie RMs doing the daily business and the veteran RM not being actively involved (at least not publicly). Communication-wise as a core developer, I also feel that it was helpful to have just two direct and authoritative contacts in case of questions or when decisions need to be made where I could trust the opinion of any one of those two. If there were three active RMs, I feel like I would want a 2 of 3-person agreement, which just adds overhead to the communication.
Best regards
Tim Düsterhus