On Mon, Mar 19, 2012 at 11:02 PM, Konstantin Shvachko <shv.had...@gmail.com> wrote: > Feature freeze has been broken so many times for the .20 branch, so > that it became a norm for the entire project rather than an exception, > which we had in the past.
I agree we should be stricter about what feature backports we allow into "stable" branches. Security and hflush were both necessary evils - I'm glad now that we have them, but we should try to stay out of these types of situations in the future where we feel compelled to backport (or re-do in the case of hflush/sync) such large items. > > I don't understand this constant segregation against Hadoop .22. It is > a perfectly usable version of Hadoop. It would be waste not to have it > released. Very glad that universities adopted it. If somebody needs > security there is a number of choices, Hadoop-1 being the first. But > if you cannot afford stand-alone HBase clusters or need to combine > general Hadoop and HBase loads there is nothing else but Hadoop 0.22 > at this point. I don't see what HBase has to do with it. In fact HBase runs way better on 1.x compared to 0.22. The tests don't even pass on 0.22 due to differences in the append semantics in 0.21+ compared to 0.20. Every production HBase deploy I know about runs on an 1.x based distribution. You could argue this is selection bias by nature of my employer, but the same is true based on emails to the hbase-user lists, etc. This is orthogonal to the discussion at hand, I just wanted to correct this lest any users get the wrong perception and migrate their HBase clusters to a version which is rarely used and strictly inferior for this use case. -Todd -- Todd Lipcon Software Engineer, Cloudera
