On Fri, Sep 9, 2011 at 1:46 PM, Roy T. Fielding <[email protected]> wrote: > On Sep 9, 2011, at 11:08 AM, Eli Collins wrote: >> The release manager - not the developers - are responsible for and >> have the final say as to what patches get merge to their branch. > > That is simply false. At no time is any individual responsible for > any part of Apache subversion, no matter how obscure the branch.
This seems to contradict the Apache release policy (http://httpd.apache.org/dev/release.html), and the practice adopted by this project. Eg "Regarding what makes it into a release, the RM is the unquestioned authority. No one can contest what makes it into the release." If there is no individual responsible for a release branch then who is "the RM" that is the unquestioned authority for a release? The page states that "there is no set RM" however in our project Nigel, Arun, and Matt volunteered to RM 22, 23 and 20x respectively. Are these people in fact not responsible for their release branches in svn, eg any committer is free to merge a patch from trunk into one of these branches? For completeness, Chris proposed a while back [1] that the RM is selected by majority PMC approval. He never proposed a vote to adopt these rules, but if we did, would they be invalid, ie according to other rules established at Apache? Ie does this project have the ability to establish it's own rules/norms w/o you telling us how our project works? 1. http://mail-archives.apache.org/mod_mbox/hadoop-general/201005.mbox/%[email protected]%3E > No RM has the final say on anything other than their own work. The release policy - "Regarding what makes it into a release, the RM is the unquestioned authority" - seems to indicate "the RM" has final say about what makes it into a release. This implies that either the release is just the RM's work (vs the work of the community) or in fact the RM is not the unquestioned authority on a release. I think there's a huge gap between the current understanding of the RM in our community and what you've outlined. Thanks, Eli
