On Tue, Jun 22, 2010 at 9:05 PM, Stack <st...@duboce.net> wrote: > On Tue, Jun 22, 2010 at 6:35 PM, Todd Lipcon <t...@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
