hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@gbiv.com>
Subject Re: abandoning 22 - was: Content request for 0.20.205 Sustaining Release
Date Sat, 10 Sep 2011 00:48:21 GMT
On Sep 9, 2011, at 2:41 PM, Eli Collins wrote:

> On Fri, Sep 9, 2011 at 1:46 PM, Roy T. Fielding <fielding@gbiv.com> 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/%3Ch2q1267dd3b1005041331r7d8f696di370a279ff605832f@mail.gmail.com%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.


View raw message