hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Hammerbacher <ham...@cloudera.com>
Subject Re: DISCUSSION: Cut a hadoop-0.20.0-append release from the tip of branch-0.20-append branch?
Date Fri, 24 Dec 2010 01:32:04 GMT
After reading through the reasoning on both sides of this issue, I agree
with Ian, Konstantin, and Jakob. Nigel has already volunteered to run the
0.22 release process; let's put our energy there. Stack, the energy you
would have put into the 0.20-append release could help ensure the 0.22
release makes it out in short order. That way HBase will be able to take
advantage of both append (don't lose data) and security (don't give it
away), and we won't derail the Hadoop Core release process, which has
actually been regaining some momentum over the past several months: we got
0.21 out the door! we have a release manager for 0.22!

As Roy points out, the Apache Hadoop release train has already passed 0.20;
for those that require a 0.20-based HDFS with append, there are multiple
places in the open source world to retrieve such bits, including the
0.20-append branch of the HDFS project. If the HBase community requires an
ASF project to release such an artifact, as Roy points out, it can certainly
done as a new project separate from HDFS.

On Thu, Dec 23, 2010 at 4:36 PM, Andrew Purtell <apurtell@apache.org> wrote:

> 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 <ryanobjc@gmail.com> wrote:
>
> > From: Ryan Rawson <ryanobjc@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.hadoop@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 <ryanobjc@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
> > <jghoman@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
> > <mcsrivas@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 <omalley@apache.org>
> > >> wrote:
> > >> >>
> > >> >>> On Wed, Dec 22, 2010 at 11:07 PM, Roy
> > T. Fielding <fielding@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
> > >> >>>
> > >> >>
> > >> >
> > >>
> > >
> >
>
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message