[
https://issues.apache.org/jira/browse/HBASE-11730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14096243#comment-14096243
]
Lars Hofhansl commented on HBASE-11730:
---------------------------------------
+1 to everything Andy said.
Not sure we need to document this. An RM is just somebody who volunteers to do
that. In some projects there's an RM for each individual release. In HBase we
happen to come to a model where the same person does all the releases for a
particular major version. We're not very formal about this.
> Document release managers for non-deprecated branches
> -----------------------------------------------------
>
> Key: HBASE-11730
> URL: https://issues.apache.org/jira/browse/HBASE-11730
> Project: HBase
> Issue Type: Task
> Components: documentation
> Reporter: Sean Busbey
>
> New development goes against trunk and is backported as desired to existing
> release branches. From what I have seen on the jira, it looks like each
> branch's release manager makes the call on backporting a particular issue.
> We should document both this norm and who the relevant release manager is for
> each branch.
> In the current docs, I'd suggest adding the RM list to the "Codelines"
> section (18.11.1) and add a brief explanation of pinging the RM as a new
> section after "submitting a patch again" (18.12.6).
> Post HBASE-4593, the note about pinging a prior branch RM should just go as a
> bullet in the "patch workflow."
--
This message was sent by Atlassian JIRA
(v6.2#6252)
