|
|
-
Re: Some notes from the HBase developer Pow-WowAndrew Purtell 2013-02-20, 02:51
Sorry I couldn't make it up for the powwow.
Thanks Devaraj for the excellent notes. On this part: -- Branching on a big feature was suggested - --- Issues: committer needs to be there Sergey: If the rate of change is high on common code (to the branches) then merging will be tough --- Jon: Refactor should be done in the main branch (since it doesn't add any new funtionality) I like how snapshots was branched and worked on collaboratively up in GitHub. It's pretty painless to rebase with git but painful to keep a branch up to date with subversion then merge back (at least for me). I have something in the works that has to be out of tree for a while because it depends on new APIs for Hadoop Common. Was thinking it should go up into GH in the meantime. Makes sense for big features to go on a branch and then be subject to the 3 +1 rule for merge. More eyes on the change. Also makes sense for refactors to be done in place. They may cause pain for work on a branch, but it's less painful to merge in as it happens on the main branch than sort out collisions later if a refactor and feature want to go in at about the same time. And on this part: - A bunch of discussions on the RPC with KeyValue/Cells .... / Tags :-) On Tue, Feb 19, 2013 at 5:27 PM, Devaraj Das <[EMAIL PROTECTED]> wrote: > - Stabilizing 0.96 / CI > -- not running continuously > -- Roman: is it a good idea to run IT under Bigtop > - the HBase unit tests are good.. > - What about HBase as a backend for hive - tests for those > - Do we think there is value with the integration with the rest > of the hadoop ecosystem > -- Jon: What's needed to make this work > -- Roman: Collective agreement that we want to solve this > -- Stack: We need to run the IT tests from Enis and Sergey running > continuously > -- Roman: If we all agree that this is something needs to be fixed > .. then yes we would talk about mechanics. Bigtop doesn't have > expertise in HBase and hence HBase folks would have to debug failures. > -- Roman: Bigtop is committed to tests. Less than a dozen tests for > hbase currently.. > -- We have been running validation around RC time. Find all kinds of > issues - sometimes trivial (maybe a config issue), > -- Roman can offer CI for trunk but will work for only hadoop-2 line. > -- Roman does first line of triage. > -- No issues to do with other ecosystem artifacts. Bigtop ensures > the right artifacts are in place. > -- hadoop-2 is important but not particular about the version of > hadoop within 2. For example 2.0.2 > -- Gary: Will be good to run security tests > -- Roman & Devaraj to talk on how this can be done/implemented > > On 0.96 branching > - Lars: > -- We will have three branches to maintain. > - Stack: we need to stabilize quickly > - Enis: What about 0.95. > - Stack: Just do the snapshots thing. Every week, give a snapshot > - Enis: we've done a bunch of stuff in RPC.. If we have to break > something, we can if it is beta (0.96-beta). > - Agreement is there generally ... Debate on the name with snapshot > versus 95.0/96.0 > -- 0.95 experimental .. 0.96 will be stable > -- If we go with 0.95, releasing will be easier as well.. > -- 0.95 will not be in production.. > -- 0.96 will be off 0.95 branch and not trunk based > > - How do we go about committing issues.. (issue commit rate is low) > -- 0.94 is stable - 2 new commits and 2 new bugs a day > -- 0.96 has lots of issues not reviewed > -- Break up the patch into multiple smaller pieces to make review easier > -- Branching on a big feature was suggested - > --- Issues: committer needs to be there > Sergey: If the rate of change is high on common code (to the > branches) then merging will be tough > --- Jon: Refactor should be done in the main branch (since it > doesn't add any new funtionality) > --- Release often to reduce #backports overall and issues with that.. > > - Review process .. how to drive a review to closure. Effort goes Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White) |