hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Rawson <ryano...@gmail.com>
Subject Re: 0.89.20100621 development branch status
Date Wed, 23 Jun 2010 23:16:38 GMT
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.


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
>

Mime
View raw message