hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Douglas <cdoug...@apache.org>
Subject [DISCUSS] secure 0.20-based branch
Date Sat, 24 Apr 2010 05:38:07 GMT
> I'm not proposing any more back- or forward-porting than will be done anyway.

That's probably true for this release, but what about HDFS-200? With
security and sync in 0.20, there is less motivation to move back to
trunk, which has diverged significantly. Moving off of 0.20 will be a
struggle without these supplements. With a weak trunk, the
justifications that led to the current state will remain in force.

>  Or, with a bit more effort, we can probably apply the patches from Jira in the right
order.  Otherwise, Cloudera, Facebook and others will have to duplicate this effort.

Cloudera, Facebook, and others could also help to finish this work in
trunk. Or clone from github if the need is dire.

> Then bugfix patches and releases can be made against this repo rather than everyone having
to assemble and maintain their own 0.20 security patchset from scratch.  Everyone will be
using this patchset for quite some time.  Why shouldn't we share a repo that contains it?

Because trunk is the shared repository that contains the security
work. And a working append. And dozens of smaller, but important
features including the 1.0 APIs. Symlinks. Optimizations to the
shuffle. Splittable bzip compression. Stability and scalability fixes
to the NameNode and JobTracker. Unicorns and happiness.

Stabilizing, packaging, and testing trunk is drudgery, but it can be shared.

I can see the value in restarting collaboration between major
contributors by reestablishing a common branch, and 0.20 will probably
be more successful in that respect, at least earlier. However, I
continue to oppose sinking combined energy into 0.20 at the expense of
trunk, for reasons already discussed at length. -C

> Doug
>

Mime
View raw message