Clarify policy for Release Manager Selection#28
Conversation
| security-only phase). | ||
|
|
||
| Release managers SHOULD NOT be a hands-off release manager for more than one | ||
| actively supported PHP version at the same time. |
There was a problem hiding this comment.
The only exception that I can think of here, is that if a hands-on one disappears, and the hands-off one needs to take over for an extended amount of time.
There was a problem hiding this comment.
That's why I used a SHOULD here. With the current practice of current hands-on 👉 next hands-off, there should not be a situation where any RM does more than one hands-off release, but I don't think it is necessary to make this a hard blocker, since I expect it to be reasonably unlikely for a hands-on RM to disappear (particularly not in the first two years).
| See the call for PHP 8.6 release managers as an example: | ||
| https://news-web.php.net/php.internals/130240 | ||
|
|
||
| Voting is conducted using "Single Transferrable Vote" (STV) method. |
There was a problem hiding this comment.
As Jakub indicated, I think we should include a way that if no volunteer seems to clear a "safe pair of hands" bar, then we need find another solution/person. I would in such case rather have a hands-off RM manage another release, then an unsuitable person. The trick is naturally how to set a bar for "Safe pair of hands".
There was a problem hiding this comment.
Where did Jakub indicate that? But I don't think this is a concern in practice, we have always managed to find (new) RMs that were suitable and with the limit of “at most one hands-on release”, just 6 folks would be sufficient to manage releases, while staying fully in line with the proposed policy:
- 8.5: hands-on: A + B; hands-off: Z
- 8.6: hands-on: C + D; hands-off: A
- 8.7: hands-on: E + F; hands-off: C
- 8.5 goes out of active support
- 8.8: hands-on: A + B; hands-off: E
- 8.6 goes out of active support
- 8.9: hands-on: C + D; hands-off: B
- 8.7 goes out of active support
Co-authored-by: Juliette <663378+jrfnl@users.noreply.github.com>
3 participants
No description provided.