On Thu, Dec 23, 2010 at 9:38 AM, Jakob Homan <jgho...@gmail.com> wrote:
> 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). > Regardless, there will still be 2 incompatible "branches". And that is only the beginning. Some future features will be done only on branch 1 (since company 1 uses that), and other features on branch 2 (by company 2, since they prefer branch 2), thereby further separating the two branches. If the goal is to avoid the split, then there are only 2 choices: (a) merge both (b) abandon one or the other. Which one is one willing to stomach? > > 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 > >> > > >
