How does stack volunteering his time to release an existing branch divert resources?
Without an ASF release of 0.20-append I will keep having to recommend an external vendor's release of Hadoop. On Thu, Dec 23, 2010 at 2:18 PM, Konstantin Shvachko <shv.had...@gmail.com> wrote: > I also think building 0.20-append will be a major distraction from moving > 0.22 forward with all the great new features, including the new append > implementation, sitting on the bench because we are delaying the release. > It seems to be beneficial for the entire community to focus on 0.22 rather > than chasing both birds. > > I hear a concern that 0.22 will lack large scale testing as was the case > with 0.21. > I'd like to volunteer to put as many large scale resources, as I can grasp, > into stabilizing of 0.22. Under Nigel's management of course. > This should get us to production quality in 3-6 months rather than > "another 12-15". I also hope it can go even faster/better if others > could join the effort. I see > 100 companies claiming they are powered by > Apache Hadoop. > > I also hope with this effort HBase will be able to start moving to the new > append implementation in the next 2-3 months, which in turn will help 0.22 > HDFS > rather than divert resources from it as it would have be with 0.20-append. > > Stack, will this plan will work for HBase survival? > > One other thought. Apache Hadoop community is not in control of external > releases and distributions, but we should not fork our own releases by > introducing > competing apis. If we can keep the dev line relatively straight the external > releases > will follow. > > Thanks, > --Konstantin > > > On Thu, Dec 23, 2010 at 11:40 AM, Ryan Rawson <ryano...@gmail.com> wrote: > >> The append solution in 0.22 that you are referring to was supposed to >> be out 13-15 months ago. Pardon if I look for solutions that deploy 4 >> months ago (as the 0.20 append branch did). >> >> Another 12-15 months of delay is not exactly helping HDFS either. >> >> -ryan >> >> 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). >> > >> > 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 >> >>> >> >> >> > >> >
