hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug Cutting <cutt...@apache.org>
Subject Re: Hadoop support for hbase
Date Fri, 07 May 2010 19:26:05 GMT
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.

Doug

Mime
View raw message