> Given, the 'feature' regressions in MR (security, operability etc. - > http://s.apache.org/critical-0.22.0), I propose we mark hadoop-0.22.0 as > 'alpha' quality too with necessary statutory warnings to end users to alert > them to the differences in terms of missing features. Else, we could land up > confusing users - this has come up before on this list: > http://s.apache.org/Go9. Seems reasonable? >
Yes the community can decide to qualify hadoop-0.22.0 as 'alpha'. As RM I only propose a release candidate, everybody else can evaluate the quality. We can have a discussion in a separate thread. Based on my personal experience I would not qualify it as "not yet ready for serious use". > On a related note - it would help if you could share your thoughts on the > roadmap for releases off branch-0.22. > Some questions come to mind, these would help the community (and, of course, > end-users) evaluate current & future releases of the branch: > # Do you plan to fix security in branch-0.22? > # Do you plan to _test_ security end-to-end for the whole ecosystem? > # Do you plan to fix some of the critical operability features such as > disk-fail-in-place, MR tasklogs' handling etc.? > # Could you share any details on the performance work/benchmarks you've done > for 0.22? How does it compare to hadoop-0.20.2xx for e.g.? Various folks, at > different points, have noticed performance regressions in branch-0.22 - have > you checked? > # Do you have timelines in mind for the above? These are all good questions Arun. All of these items would improve the quality of the branch. Again, I don't see RM's role as a spiritual leader drawing roadmaps for the community. We all should decide where we want to go with this and other releases. I can say for myself that I will be closely working with this branch for at least some time. And as usually will make sure to merge all findings into it. As a discussion topic (for a separate thread) we can consider two options for upgrading MR in 0.22: 1) To do forward porting of improvements from 1.0. 2) To merge MR-1.0 into branch-0.22 and make it work with HDFS.22 Ideally, it would be more productive to converge under a single branch, rather than spreading the development resources among multiple ones. Yet another way is to have a higher level of compatibility between versions/branches, so that one could mix and match components, say HDFS.22 + MR.23. I heard other people thinking along the same lines. Thanks, --Konstantin
