I hope that 22 will be an answer. I think I would be more comfortable with that
answer if Hadoop Core were not so obviously internally conflicted and
sclerotic. Potential HBase/Hadoop adopters have confidence in 20 seeing the
production deployments of it. 21 was to all indications I have seen a dud.
There is no reasonable basis as of yet to presume 22 will be "kick ass".
I, at least, was hoping that promoting 0.20-append from its de-facto status to
something official could be a fig leaf for HBase while Hadoop Core gets its
house in order.
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back.
- Piet Hein (via Tom White)
--- On Thu, 12/23/10, Ryan Rawson <ryano...@gmail.com> wrote:
> From: Ryan Rawson <ryano...@gmail.com>
> Subject: Re: DISCUSSION: Cut a hadoop-0.20.0-append release from the tip of
> branch-0.20-append branch?
> To: general@hadoop.apache.org
> Date: Thursday, December 23, 2010, 2:39 PM
> 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
> >> >>>
> >> >>
> >> >
> >>
> >
>
