Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop >> mail # general >> Hadoop support for hbase

Copy link to this message
Re: Hadoop support for hbase
On 05/07/2010 10:57 AM, Todd Lipcon wrote:
> 1) Will we open new JIRAs separately for each change we want to commit, and
> go through the normal review process? Currently the 20-append work has been
> mostly going on under HDFS-142 for whatever reason, with ancillary issues
> only for bugs that also exist in trunk.

I think the proposal discussed yesterday was that the release manager
has the power to determine which patches are merged from trunk to his
branch, to cherry pick.  But for patches that are never committed to
trunk but only to his branch, I think we should use normal rules.  Note
that, under normal rules, the release manager still has veto power over
his branch.

> The other alternative as I see it is to have those working
> on this branch do so somewhere like github - the advantages to that would be
> (a) it provides a more open way for non-committers to contribute, which is
> important since we're working closely with the HBase team on this, and (b)
> it doesn't add confusion to the main Hadoop jira and download pages. The
> disadvantage of course is that it fragments the code repository and we can't
> really do a release as easily.

If the purpose of the branch is for diverse Apache contributors to share
code and make Apache releases, we should keep it at Apache rather than
at github.

If the branch really is only intended to be used by HBase, then perhaps
the branch could live under hbase, e.g., hbase/branches/hdfs-0.20

If we think it might be used by others beyond HBase, or by clusters that
are used for more than just HBase, then we might keep it under HDFS.  We
could label it according to the feature it concerns, e.g.,
hdfs/branches/0.20-append, or, if we think it's a set of features of
which HBase is the only consumer, then hdfs/branches/0.20-hbase might
make sense.

Another alternative might be to name the branch after the release
manager.  So this could be named hdfs/branches/0.20-dhruba.  Then, when
it comes time to make a release from this branch, we might name the
release something different, like or 0.20.3 or somesuch.

This has the potential to create a lot of fragmentation.  Ultimately we
depend on the PMC to control this by not voting for releases from a
multitude of branches.  But, prior to that, we might discourage folks
from creating such branches if we think they'll unduly fragment things.

The current proposal is to fragment 0.20 into two variants, hbase and
vanilla.  It's probable that someone might also propose a secure
fragment.  Three variants might be confusing.  Is there any chance we
could combine some of these?  For example, could vanilla become secure,
or could hbase become secure?  Do folks think three fragments would be
acceptable?  If not, which would you drop or merge?

We can delay final answers to such questions until a release vote, but
it'd be good to have at least a general direction earlier.