Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop >> mail # general >> DISCUSSION: Cut a hadoop-0.20.0-append release from the tip of branch-0.20-append branch?


Copy link to this message
-
Re: DISCUSSION: Cut a hadoop-0.20.0-append release from the tip of branch-0.20-append branch?
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
>
> > From: Ryan Rawson <[EMAIL PROTECTED]>
> > Subject: Re: DISCUSSION: Cut a hadoop-0.20.0-append release from the tip
> of branch-0.20-append branch?
> > To: [EMAIL PROTECTED]
> > 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
> > <[EMAIL PROTECTED]>
> > 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,
> >