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
