hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Todd Lipcon <t...@cloudera.com>
Subject Re: 0.89.20100621 development branch status
Date Wed, 23 Jun 2010 19:27:11 GMT
On Tue, Jun 22, 2010 at 9:05 PM, Stack <stack@duboce.net> wrote:

> On Tue, Jun 22, 2010 at 6:35 PM, Todd Lipcon <todd@cloudera.com> wrote:
> >
> > Quick update on the development branch 0.89.20100621.
> >
>
> (Todd you want to explain the version number or do you want me to?)
>
>
> > I think the following patches still need to go in:
> > - HBASE-2767 (failed tests building with HDFS-1209)
>
> Reviewed.
>
> Committed


> > - HBASE-2729 (fix bug when flush hits IOE)
>
> Please paste patch into issue so can review (review.hbase.org is down)
>
>
Stack reviewed and I committed


>
> > - I'd also like to disable the TestAcidGuarantees test in this branch,
> since
> > that is a known bug.
>
> Done

>
> Grand.
>
> > - I'd like to commit a short KNOWN_BUGS file which describes a few of the
> > open issues that we're currently working on. Certainly doesn't have to be
> > exhaustive list of all open JIRAs, but just a few things that users may
> run
> > into.
> >
>
> Yeah.  Just call out the biggies and refer use to the short list
> (ahem) of other issues we have against next major release.
>
> Done

>
> > Some performance issues were raised during testing at StumbleUpon -- any
> > luck figuring those out, Ryan/Stack? It would be good to address them for
> > the dev release, since it sounds like the RS barely makes progress when
> this
> > bug is triggered.
> >
>
>
> Yeah, its a beaut.  Sucks all resources for some period of time until
> it gets over first flush then its  good to go for a while at least.
> Still trying to figure it.
>
>
This one is still mysterious - it happens a lot over at StumbleUpon but I
haven't been able to repro on my cluster. I put it in the known bugs list.


>
> > Given the above, I'd like to see if we can get the above two jiras
> reviewed
> > and committed later tonight, and I'll try to roll a release candidate
> before
> > I go to sleep. I think the correct way to release in this maven land is
> to
> > simply do an svn export and vote on that, and then separately do an
> > assembly:assembly tar as a binary release artifact (since assembly tar
> > doesn't include unpacked source, etc).
> >
>
> Why not just vote on the assembly?  Thats what we'd run?   If you do a
> site before assembly:assembly, you'll even have docs (mvn install site
> assembly;assembly).  The source is there to review if wanted.  Doing
> an svn export will have to build ourselves.
>
>
Doug says:
"Yes, as an open-source foundation, ASF projects fundamentally produce
source-code releases.  Binaries are optional, sources not.

Overall this sounds like a good plan.  An ASF release needn't be top-quality
and bug-free, but it needs to be voted on.  When voting on a release a
primary concern should be that it contains properly licensed code.  Voters
may additionally wish releases to have a certain level of quality, e.g.,
more for final releases than snapshot releases, but that's not a requirement
of every ASF release."

So until we figure out a way to make a mvn assembly that is
self-hosting/recompilable, let's just vote an an svn export tarball. Of
course right next to it will be a "bin" tarball (which includes src jar,
bin, docs, etc)

Given that I think we have everything in place, I'm going to kick off some
new cluster tests here and start a vote thread.

-Todd

-- 
Todd Lipcon
Software Engineer, Cloudera

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