hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mattmann, Chris A (388J)" <chris.a.mattm...@jpl.nasa.gov>
Subject Re: abandoning 22 - was: Content request for 0.20.205 Sustaining Release
Date Fri, 09 Sep 2011 23:56:35 GMT
Chris,

Well put, +1.

Cheers,
Chris

On Sep 9, 2011, at 4:42 PM, Chris Douglas 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


++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW:   http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


Mime
View raw message