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
On Sat, 28 Mar 2026, Ben Ramsey wrote:
On 3/27/26 13:15, Tim Düsterhus wrote:
>
> 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.6I'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 tenureThe 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."
I agree with all of these points.
I don't think we even should say that a "veteran RM being one of the RMs
of the *previous* PHP version". A previously active one should be fine
too.
cheers,
Derick
Hi
I was waiting for the RM vote to end before replying here further to not influence the active vote.
Am 2026-03-31 12:08, schrieb Derick Rethans:
I don't think we even should say that a "veteran RM being one of the RMs
of the *previous* PHP version". A previously active one should be fine
too.
My proposal specifically uses the term “customary” here: For PHP 8.2, 8.3, 8.4, and 8.6 it was a hands-on RM of the previous release who did the hands-off duty for the next release (PHP 8.5 was an exception to this pattern). I also think it makes sense for two reasons:
- It ensures that the knowledge of the hands-off RM is up to date with the most recent practices and workflows.
- It only extends the existing duty by one additional year, since the hands-off tasks can run alongside the hands-on tasks for most of the time.
But I agree that it is not *necessary* to strictly follow this rule, anyone who already did hands-on duty is qualified for hands-off duty.
Best regards
Tim Düsterhus
Hi
Am 2026-03-27 19:15, schrieb Tim Düsterhus:
please find the following RFC that is intended to clarify the “Release Manager Selection” policy for future PHP versions:
I've made some changes to the PR to streamline the language a little more and use consistent terminology to refer to various “relative” PHP versions (e.g. “upcoming PHP version” for the PHP version that we're going to elect RMs for).
Please check the commits for more details.
I consider this a major change. Given how quiet this discussion was, I plan to vote on the RFC once the cooldown period expires. I'll send an official intent to vote when this date comes closer.
Best regards
Tim Düsterhus
On 5/3/26 08:11, Tim Düsterhus wrote:
Hi
Am 2026-03-27 19:15, schrieb Tim Düsterhus:
please find the following RFC that is intended to clarify the “Release Manager Selection” policy for future PHP versions:
I've made some changes to the PR to streamline the language a little more and use consistent terminology to refer to various “relative” PHP versions (e.g. “upcoming PHP version” for the PHP version that we're going to elect RMs for).
Please check the commits for more details.
I consider this a major change. Given how quiet this discussion was, I plan to vote on the RFC once the cooldown period expires. I'll send an official intent to vote when this date comes closer.
Best regards
Tim Düsterhus
I still dislike the distinction of "hands-on" and "hands-off" as descriptors for these roles and disagree with their use in defining these roles. I said as much in my earlier message, and I'll be voting "no" for the changes to the policy as it currently stands.
I think I'm in agreement with the rest of the proposal. If we can come up with better terminology around the roles and make the roles less about their level of involvement, then I'll probably change my vote to a "yes."
Cheers,
Ben
On 5/3/26 09:40, Ben Ramsey wrote:
On 5/3/26 08:11, Tim Düsterhus wrote:
Hi
Am 2026-03-27 19:15, schrieb Tim Düsterhus:
please find the following RFC that is intended to clarify the “Release Manager Selection” policy for future PHP versions:
I've made some changes to the PR to streamline the language a little more and use consistent terminology to refer to various “relative” PHP versions (e.g. “upcoming PHP version” for the PHP version that we're going to elect RMs for).
Please check the commits for more details.
I consider this a major change. Given how quiet this discussion was, I plan to vote on the RFC once the cooldown period expires. I'll send an official intent to vote when this date comes closer.
Best regards
Tim DüsterhusI still dislike the distinction of "hands-on" and "hands-off" as descriptors for these roles and disagree with their use in defining these roles. I said as much in my earlier message, and I'll be voting "no" for the changes to the policy as it currently stands.
I think I'm in agreement with the rest of the proposal. If we can come up with better terminology around the roles and make the roles less about their level of involvement, then I'll probably change my vote to a "yes."
Cheers,
Ben
Following up on my earlier messages, I've been thinking more about the terminology and have come up with a concrete suggestion.
From my perspective, the distinction between the two roles is fundamentally about experience, not involvement. I don't want to define the roles around involvement. The policy itself already uses the word "veteran" to describe the qualification for the advisory role, so I'd suggest elevating that to the name of the role itself: "Veteran Release Manager" for the advisor with prior experience, and "Co-release Manager" for the other two. This reuses terminology already present in the policy text and defines the roles by what qualifies someone for them rather than what they're expected to do or not do. It also leaves room for the RMs themselves to organize their work as they see fit.
With these changes I'd be comfortable changing my vote to "yes."
Cheers,
Ben
I agree with Ben, I would prefer “Veteran Release Manager” / “Co-release Manager” over “hands on” / “hands off”. The “hands off” sounds negative to me.
Hi
Am 2026-05-03 17:29, schrieb Ben Ramsey:
From my perspective, the distinction between the two roles is fundamentally about experience, not involvement.
I refer to my reply to Jordi, particularly the second paragraph.
I don't want to define the roles around involvement.
The policy is describing the current practice in a formal way. For the past several releases only two of the three release managers have actually made releases [1]. For PHP 8.5 specifically, all the public communication and PR review during the feature freeze has been done by the two “rookies” / “hands-on” RMs Daniel and Volker. I'd argue that this hands-on and hands-off split is already something that is expected by the community.
The policy itself already uses the word "veteran" to describe the qualification for the advisory role, so I'd suggest elevating that to the name of the role itself: "Veteran Release Manager" for the advisor with prior experience, and "Co-release Manager" for the other two. This reuses terminology already present in the policy text and defines the roles by what qualifies someone for them rather than what they're expected to do or not do. It also leaves room for the RMs themselves to organize their work as they see fit.
I'm not seeing the term “co-release manager” in the policy. I'd also like to note how you used the word “advisor” to refer to what my proposal refers to as “hands-off”.
Best regards
Tim Düsterhus
[1] With one exception for PHP 8.3.1 and one for PHP 8.0.30, the latter of which has been made without even being an official RM. I remember this causing some troubles for Docker, which didn't expect the “extra PGP key”.
php-8.5.0 Daniel Scherzer
php-8.5.0RC1 Daniel Scherzer
php-8.5.0RC2 Volker Dusch
php-8.5.0RC3 Daniel Scherzer
php-8.5.0RC4 Volker Dusch
php-8.5.0RC5 Daniel Scherzer
php-8.5.0alpha1 Daniel Scherzer
php-8.5.0alpha2 Volker Dusch
php-8.5.0alpha3 Daniel Scherzer
php-8.5.0alpha4 Daniel Scherzer
php-8.5.0beta1 Volker Dusch
php-8.5.0beta2 Daniel Scherzer
php-8.5.0beta3 Volker Dusch
php-8.5.1 Volker Dusch
php-8.5.1RC1 Volker Dusch
php-8.5.1RC2 Volker Dusch
php-8.5.2 Daniel Scherzer
php-8.5.2RC1 Daniel Scherzer
php-8.5.3 Volker Dusch
php-8.5.3RC1 Volker Dusch
php-8.5.4 Daniel Scherzer
php-8.5.4RC1 Daniel Scherzer
php-8.5.5 Volker Dusch
php-8.5.5RC1 Volker Dusch
php-8.5.6RC1 Daniel Scherzer
php-8.5.6RC2 Daniel Scherzer
php-8.5.6RC3 Daniel Scherzer
Hi
Am 2026-05-03 15:11, schrieb Tim Düsterhus:
I consider this a major change. Given how quiet this discussion was, I plan to vote on the RFC once the cooldown period expires. I'll send an official intent to vote when this date comes closer.
The cooldown will expire in roughly 24 hours. I plan to start the vote early next week.
Best regards
Tim Düsterhus