Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <AANLkTik-DgcN3aSHoi5k5jTfPPq9jZV-nTV7qIZpF-QR@mail.gmail.com>
References: <AANLkTikYzIqLHYrUdpbr5BDdQ22fahhvAp0tA3mCfaXC@mail.gmail.com>
	<AANLkTinmqSu4Pk9B6HmwNaqIq98wgzWAniHCDkHJhkfQ@mail.gmail.com>
	<AANLkTiklq3VbPJ6Uy2LvPEyY1wNhNYpvm6TovVy3vGyf@mail.gmail.com>
	<AANLkTik-DgcN3aSHoi5k5jTfPPq9jZV-nTV7qIZpF-QR@mail.gmail.com>
From: Todd Lipcon <todd@cloudera.com>
Date: Wed, 23 Jun 2010 16:35:24 -0700
Message-ID: <AANLkTikl8c0WIzC0jDxeABn1IElxp9TOiggkP_SIXYAR@mail.gmail.com>
Subject: Re: 0.89.20100621 development branch status
To: dev@hbase.apache.org
Content-Type: multipart/alternative; boundary=0016e64754ca22e5210489baffa9

--0016e64754ca22e5210489baffa9
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Jun 23, 2010 at 4:16 PM, Ryan Rawson <ryanobjc@gmail.com> wrote:

> By moving away from spins to explicit synchronization we managed to
> squish the bug we have been seeing.  I also moved us to use volatiles
> in RWCC just because.  We should probably ship with this patch once
> it's committed.
>
>
OK, I can build a new rc later tonight. Let's keep testing the previous one,
though, and count a +1 towards either as a +1 towards both :)

-Todd


>
> On Wed, Jun 23, 2010 at 12:27 PM, Todd Lipcon <todd@cloudera.com> wrote:
> > 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
> >
>


-- 
Todd Lipcon
Software Engineer, Cloudera

--0016e64754ca22e5210489baffa9--