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
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
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
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
> -- 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
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)