Thanks for the summary Deveraj.
The webex recording for the meeting is at:
Please let me know if you cannot access it.
On Tue, Feb 19, 2013 at 5:30 PM, Jean-Marc Spaggiari <
[EMAIL PROTECTED]> wrote:
> Thanks a for those notes Devaraj!
> Very useful for the unfortunates who did not got the chance to join the
> meeting ...
> Le 19 févr. 2013 20:27, "Devaraj Das" <[EMAIL PROTECTED]> a écrit :
> > - 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
> > waste if the review process is not completed. The same reviewer should
> > continue to review the patch ..
> > - Hard to enforce any process
> > - Enis: there should be a summary of the patch and all that .. so that
> > the review process is helped.. Hard to understand the architecture of
> > the patch unless documented
> > - Jon: It should be easy to make a one-to-one correspondence between
> > the description and the patch
> > - The commit should have only the jira# as opposed to pages of
> > - Component owners: is this working. Committers need to be forthcoming
> > with reviews
> > -- Maybe review the modules and add some more if needed.