On Sep 9, 2011, at 2:41 PM, Eli Collins wrote: > 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."
I think someone got carried away in their artistic flair. I wrote the original httpd guidelines. > 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. Volunteers are always needed. That doesn't mean they are the only volunteers, nor does it mean they have special veto powers. > 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? Any committer can commit wherever they have been given permission to commit by the PMC. Generally, they do so collaboratively. I've never encountered a situation in my own projects which developers were committing at cross-purposes, even when they disagree on content, though I've seen commit wars elsewhere. We'd expect the PMC to step in if they did. The only thing the RM has authority over is the building of a source package, based on the contents of our subversion, that can then be put up for vote. They can decide what snapshot to tag for a build. They can decide not to build anything at all. They can also do all sorts of organizational support, advocacy, pleading, or whatever in order to encourage the rest of the project committers to apply changes, vote for things under issue, etc. They do not have the right to pick and select whatever variation of the product they might like to build, short of vetoing (with a valid reason) any changes that they as a PMC member believe do not belong on the branch. Likewise, the RM cannot include in the build any change that has been vetoed by others, and their build cannot be released if it contains any such changes that have been vetoed since it was built. The RM has the right to kill their own build if they learn something during the release process that they think, for whatever reason, causes the build to be unreleasable. But the RM can't stop anyone else on the PMC from taking the same build and calling for its release under their own management as RM. > 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 The ASF supports collaborative development of open source through the work of individual volunteers. If the rules are consistent with that mission and are applied consistently, then the board is unlikely to intervene. As a board member, what I look for is the effect that those rules have on collaboration. If I see a bunch of happy developers collaborating on releases, it really doesn't matter what the rules are since the rules exist to prevent technical disagreements from escalating into social conflicts. If, however, I see no significant releases, work being done elsewhere, or the project split into multiple branches that happen to match corporate fiefdoms, then it is my responsibility to do something to get it back to being a collaboration. Sometimes that means we change the rules. ....Roy
