hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Douglas <cdoug...@apache.org>
Subject Re: abandoning 22 - was: Content request for 0.20.205 Sustaining Release
Date Fri, 09 Sep 2011 23:42:17 GMT
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

View raw message