hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eli Collins <...@cloudera.com>
Subject Re: abandoning 22 - was: Content request for 0.20.205 Sustaining Release
Date Sat, 10 Sep 2011 00:34:17 GMT
On Fri, Sep 9, 2011 at 4:42 PM, Chris Douglas <cdouglas@apache.org> wrote:
> On Fri, Sep 9, 2011 at 2:41 PM, Eli Collins <eli@cloudera.com> wrote:
>> 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 intent was to evolve the policies we had at the time to an RM-like
> role. As Tom raised in that thread, much of the intermediate phase is
> unnecessary. In the project's current state, much of that proposal is
> no longer coherent.
> For instance, electing an RM is an unnecessary formality. Further,
> enforcing the version compatibility rules across the 0.20.2xx and
> various 0.2x branches is prohibitively expensive. As demonstrated by
> previous experience, making prohibitively expensive rules motivates
> external forks, not coherence. They're useful guidelines for what the
> PMC is likely to approve, but I expect we'll show more flexibility
> than what that proposal outlined.
> In practice, we already exercise all the important elements of that
> proposal. Someone creates a branch and intends to release from it,
> others may help them, and if an artifact is produced then the PMC
> votes on whether to release it. Any debate, accusation, and
> recrimination concerning "investing" in a branch is pointless because
> the "result" of the debate is irrelevant. Other than venting some
> spleen, this thread has no functional consequence.
> On Fri, Sep 9, 2011 at 1:46 PM, Roy T. Fielding <fielding@gbiv.com> wrote:
>>> No RM has the final say on anything other than their own work.
> That's consistent with the position as forwarded. We're using "the
> RM's branch" as a shorthand for "whatever the RM has elected to
> include." Your comments highlight nuance, not fundamental dissonance.
>> I think there's a huge gap between the current understanding of the RM
>> in our community and what you've outlined.
> It's vanishingly small, but important. Ownership of a branch isn't
> vested in an RM, neither is it transferrable. If someone wanted to
> commit something to a branch, they aren't required to ask the RM. Now,
> it's *polite*, and I hope that most would give a heads-up for anything
> they were unsure of, but the repository isn't a hierarchy of
> dictatorships. The source tree is lock-free. -C

I think the main point is that RMs correspond to releases, not a
release branch. This distinction makes more sense, eg I think it would
be good to have a set of people RM the dot releases off a given branch
instead of an RM for a branch and a series of releases from it (what
it seems like we've been doing).


View raw message