Skip to content

Clarify policy for Release Manager Selection#28

Draft
TimWolla wants to merge 5 commits intophp:mainfrom
TimWolla:release-manager-selection
Draft

Clarify policy for Release Manager Selection#28
TimWolla wants to merge 5 commits intophp:mainfrom
TimWolla:release-manager-selection

Conversation

@TimWolla
Copy link
Copy Markdown
Member

No description provided.

Comment thread release-process.rst
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.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Comment thread release-process.rst
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.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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".

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Comment thread release-process.rst Outdated
Co-authored-by: Juliette <663378+jrfnl@users.noreply.github.com>
Comment thread release-process.rst Outdated
Comment thread release-process.rst

The hands-off release manager MUST be a veteran release manager, meaning they
MUST have previously served as a release manager. The hands-off release manager
SHOULD be a hands-on release manager of a currently supported PHP version. It is
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"of a currently supported PHP version" as of when? I assume this is "as of selection and/or GA", but we should be clear

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is identical, because the support expires at the end of a calendar year and both selection and GA is happening in the same year. I'm noting though that I explicitly mentioned “including the pre-release period” further below.

Comment thread release-process.rst Outdated
Co-authored-by: Daniel Scherzer <daniel.e.scherzer@gmail.com>
Comment thread release-process.rst Outdated
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants