hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Rawson <ryano...@gmail.com>
Subject Re: Vote on 0.20.3.1
Date Wed, 07 Apr 2010 05:24:29 GMT
I don't get it - why did we commit all those things to 0.20 branch if
they are not suitable for the next release?

If we did accidentally commit things that are not suitable for 0.20.4,
then we should revert them asap and make a 0.20.4 release from branch.
 Branching your release branch is... not a good idea.

On Tue, Apr 6, 2010 at 10:50 AM, Jean-Daniel Cryans <jdcryans@apache.org> wrote:
> I created a new branch from rev 919707 from which we will be able to tag 0.20.4:
>
> https://svn.apache.org/repos/asf/hadoop/hbase/branches/0.20_pre_durability/
>
> And I committed the following on top of it:
>
>   HBASE-2034  Client sync block can cause 1 thread of a multi-threaded client
>               to block all others (Karthik Ranganathan via Stack)
>   HBASE-2355  Unsynchronized logWriters map is mutated from several threads in
>               HLog splitting (Todd Lipcon via Andrew Purtell)
>   HBASE-2358  Store doReconstructionLog will fail if oldlogfile.log is
>               empty and won't load region (Cosmin Lehene via Stack)
>   HBASE-2365  Double-assignment around split
>   HBASE-2174  Stop from resolving HRegionServer addresses to names using DNS on
>               every heartbeat (Karthik Ranganathan via Stack)
>   HBASE-2087  The wait on compaction because "Too many store files"
>               holds up all flushing
>   HBASE-2252  Mapping a very big table kills region servers
>   HBASE-2277  Update branch to hadoop 0.20.2
>
> HBASE-2248 should be added when it's ready for commit, then if anyone
> else thinks its missing others jiras feel free to commit them (or ask
> a committer to do it).
>
> J-D
>
> On Tue, Apr 6, 2010 at 10:31 AM, Andrew Purtell <apurtell@apache.org> wrote:
>> Yes, I mean something ready to eval and vote by the end of the week.
>>
>> 2248 should go in for a 0.20.4 RC I think, so we can vet it sooner rather than later.
Can always take it out if there are problems.
>>
>> We will have enough changes to sort out for 0.20.5 (HDFS-200 repercussions) already.
>>
>>   - Andy
>>
>>> From: Jean-Daniel Cryans
>>>
>>> Well we have to put up a RC, this would be when we have
>>> enough votes?
>>>
>>> There's also the question if 2248 should be included.
>>>
>>> J-D
>>>
>

Mime
View raw message