Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop >> mail # general >> Re: abandoning 22 - was: Content request for 0.20.205 Sustaining Release


Copy link to this message
-
Re: abandoning 22 - was: Content request for 0.20.205 Sustaining Release
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 <[EMAIL PROTECTED]> 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/%[EMAIL PROTECTED]%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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
WWW:   http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB