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 >> [DISCUSS] Hadoop Security Release off Yahoo! patchset


Copy link to this message
-
Re: [DISCUSS] Hadoop Security Release off Yahoo! patchset
On Mon, Jan 17, 2011 at 8:30 PM, Jeff Hammerbacher <[EMAIL PROTECTED]> wrote:
> We had this exact same discussion about the 0.20-append branch a few weeks
> ago. A few organizations have tested that code at scale and feel strongly
> that it's stable. We decided not to release it because it does not meet the
> Apache guidelines for a release.

It does meet the guidelines. The last validation and development of
the append work wasn't done openly, but that doesn't prevent it from
being contributed and released. That discussion died out because no
committer stepped up, rolled a release of that branch, and called a
vote. If it gets a majority of votes on the PMC, it could even be
released off the 0.20 branch. Individuals may have their reservations
and vote accordingly, but the PMC has the authority to release
0.20-append and 0.20.100 (or whatever).

> A few weeks later, we now have another organization claiming that their
> 0.20-based branch is tested at scale and should be released. It's claimed
> that 0.20.100 will be "more stable, performant and more useful to our
> users"; the same can be said of the 0.20-append branch. Neither branch,
> however, is a bugfix release and thus does not meet the Apache guidelines
> for a release. That's too bad; we should work to avoid this situation again
> in the future, but let's not try to change the rules because we did a poor
> job in the past of getting our work released via Apache.

The rules from Apache are *far* more flexible than what we've
practiced. Our rigidity has contributed to the current state of the
project by pushing active development behind the walls of contributing
organizations. We aren't obligated to live with a fractured community,
nor do some nebulous Apache guidelines prohibit us from finding a way
forward.

> As Nigel mentions, and as was done with 0.20-append, I would fully support a
> "a code-only drop into a branch w/ no formal Apache release". That's fully
> compliant with the Apache process.

This helps nobody except those who would cut releases outside of
Apache, which is precisely what we're trying to curtail.

> All of these discussions will be moot once we get 0.22 out the door and stop
> arguing over which organization has the most magical 0.20-based bits. I'm
> looking forward to seeing all of the Apache Hadoop contributors working full
> time on that release process once these bits are committed to the 0.20.100
> branch.

+1 I'm sure I'm not alone in turning ill at the thought of working on
a 0.20 branch again. But others may have different priorities,
different interests, and may actually prefer the architectural
decisions in 0.20 to those made since then. There's obviously enough
interest in a stable branch for all the major contributors to solve
those same problems independently. Opening up space in Apache for that
work is what we should have done a year ago. Since we don't yet have a
credible release, it still makes sense today. -C
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