Fair enough. Lets try and do a fast turnaround on RC3. There are two issues outstanding after jdcryans fixes for regressions and the jgray fix for balancer, as I see it. I've marked them as 0.20.0 (you are on one of them): http://su.pr/22vilt.
If there are others, speak up folks. Hopefully new RC3 by morning. St.Ack On Thu, Aug 27, 2009 at 12:24 AM, Andrew Purtell <[email protected]>wrote: > I understand your reasoning Stack. However, this project is gathering a lot > of interest and is being considered in several (many?) places. Some noobs > will find bugs (???) and make embarrassing and very public keynotes at some > major conference. Some RD teams at companies considering HBase/Bigtable as > appropriate architecture might have insufficient confidence or be actually > burned into opting for something totally sub par but "stable" such as RDBMS > sharding. Perfection is not required, but a known issue affecting stability > as according to JGs analysis of the balancing issue, or which causes data > loss as 1780 and 1784, must be fixed. I agree the rest can be pushed to a > point release. > > - Andy > > > > > ________________________________ > From: stack <[email protected]> > To: [email protected] > Sent: Wednesday, August 26, 2009 7:44:57 PM > Subject: Re: ANN: hbase 0.20.0 Release Candidate 2 available for download > > My reasoning is that RC2 has enough 'right' about it. Its radically better > than our 0.19 offering, as is. > > The benefit is that we have a week or two less of 0.19.x and that those who > only work with released software will get the new hbase earlier. > > I'm anxious to get us over this 0.20.0 hump -- yes, it will have known > defects but every release we've made has had known defects? -- and to get > the latest documentation up on our site so noobs and those whose only > interaction with the project is via hbase.org -- the marjority? -- are > using, finding bugs, and asking questions about the new rather than the > old. I'd also like to get the 0.21 hbase focus started. > > HBASE-1794 is amusing but for a fact, replay has been broken for many > releases now. > HBASE-1780 is a problem in 0.19.x > HBASE-1784 is an issue, yeah, but looks like the hadoop install is missing > hadoop-4681? > > St.Ack > > > > > > > > On Wed, Aug 26, 2009 at 8:19 AM, Andrew Purtell <[email protected]> > wrote: > > > There is a lot riding on getting this release right. There have been some > > serious bugs unearthed since 0.20.0 RC1. This makes me nervous. I'm not > sure > > I understand the rationale for releasing 0.20.0 now and then 0.20.1 in > one > > week, as opposed to taking the same amount of time to run another RC > cycle > > to produce a 0.20.0 without bad known defects. What is the benefit? > > > > HBASE-1794: Recovered data still seems missing until compaction, which > > might not happen for 24 hours. Seems like a fix is already known? > > HBASE-1780: Data loss, known fix. > > HBASE-1784: Data loss. > > > > I'll try to put up a patch/band-aid against at least one of these > tonight. > > > > HBASE-1784 is really troubling. We should roll back a failed compaction, > > not vaporize data. -1 on those grounds alone. > > > > - Andy > > > > > > > > > > ________________________________ > > From: stack <[email protected]> > > To: [email protected] > > Sent: Wednesday, August 26, 2009 4:21:33 PM > > Subject: Re: ANN: hbase 0.20.0 Release Candidate 2 available for download > > > > It will take a week or so to roll a new RC and to test and vote on it. > > > > Why not let out RC2 as 0.20.0 and do 0.20.1 within the next week or so? > > > > The balancing issue happens when you new node online only. Usually > > balancing ain't bad. > > > > The Mathias issue is bad but still being investigated. > > > > Andrew? > > > > St.Ack > > > > > > On Wed, Aug 26, 2009 at 1:04 AM, Mathias Herberts < > > [email protected]> wrote: > > > > > On Mon, Aug 24, 2009 at 16:51, Jean-Daniel Cryans<[email protected]> > > > wrote: > > > > +1 I ran it without any problem for a while. I asked Mathias if 1784 > > > > should kill it and he thinks no since it is not deterministic. > > > > > > Given the latest run I did and the associated logs/investigation which > > > clearly show that the missing rows is related to failed compactions I > > > change my mind and now think 1784 should kill this RC. > > > > > > so -1 for rc2. > > > > > > Mathias. > > > > > > > > > > > > > > > > > >
