It's difficult to support this proposal knowing how much time would be spent preparing an official release, continuing to support it and continuing to two support two separate implementations of append. I believe that effort would be better spent getting out a kick-ass 22 (or, barring that, a *really* kick-ass 23).
The Promised Land that we say we're all trying to get to is regular, timely, feature-complete, tested, innovative but stable releases of new versions of Apache Hadoop. Missing out any one of those criteria discovered will continue (and has continued) the current situation where quasi-official branches and outside distributions fill the void such a release should. The effort to maintain this offical branch and fix the bugs that will be discovered could be better spent moving us closer to that goal. I'm certainly sympathetic to the difficult position our quagmire has placed HBase into. However, the current proposal would hurt HDFS to help HBase. The best solution for that project, as well as for HDFS, is to get HDFS back to a healthy release cycle; not prolong or codify the current ad-hoc state of affairs. Let's stop digging this hole. -jakob On Thu, Dec 23, 2010 at 9:33 AM, M. C. Srivas <mcsri...@gmail.com> wrote: > [ Sorry if this is be-laboring the obvious ] > > There are two append solutions floating around, and they are incompatible > with each other. Thus, the two "branches" will forever remain incompatible > with each other, regardless of how they are numbered (0.22, 0.23, 0.20.3, > e.t.c.) > > Unless both are merged into one branch, and a switch provided to "use > HDFS-200 append" or "use 0.22 append", we have effectively split Hadoop into > two. > > > On Thu, Dec 23, 2010 at 12:00 AM, Owen O'Malley <omal...@apache.org> wrote: > >> On Wed, Dec 22, 2010 at 11:07 PM, Roy T. Fielding <field...@gbiv.com> >> wrote: >> >> > Features are not release version tags. If there is a security bug >> > found then we would have to release a new version of the append >> > version, and a round of severe trout slapping would result. >> > >> >> Yeah, it isn't a perfect solution and it doesn't scale to a second tag, but >> the problem is that this is effectively a release branch between 0.20 and >> 0.21. Of course I agree that any critical bugs would need to be fixed in >> the >> append branch as well as the 0.20 and 0.21 branches. >> >> If you want to stick to pure numbers and we want to leave ourselves a way >> to >> bugfix the 0.20 branch without append, we'd could use a version string like >> 0.20.100, etc. Not pretty, but it does preserve the numeric ordering and >> suggest a version jump. >> >> If I remember right, there were also protocol changes in the append branch, >> which was another reason we didn't want to put it directly into the 0.20 >> branch. >> >> -- Owen >> >
