Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase >> mail # dev >> Some notes from the HBase developer Pow-Wow


Copy link to this message
-
Re: Some notes from the HBase developer Pow-Wow
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)
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB