[ https://issues.apache.org/jira/browse/HBASE-11730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128179#comment-14128179 ]
Lars Hofhansl commented on HBASE-11730: --------------------------------------- BTW. a "permanent" release manager for a branch is something we informally made up. Other Apache project choose a RM for each release they do. I really think we should not make this role more than it is. An RM is not a "decider" about what goes somewhere and what not doesn't (not more than a committer would anyway), just somebody who keeps the a release (or branch) coherent. > 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 > Assignee: Misty Stanley-Jones > Attachments: HBASE-11730.patch > > > 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.3.4#6332)