Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase >> mail # dev >> Thoughts about large feature dev branches

Copy link to this message
Re: Thoughts about large feature dev branches
Hope to have time to write up some more thoughts later, but some
interesting reading is this document from Linux on how to contribute
to that project:

Worth looking at other projects' guidelines to form our own if we're
thinking of going this route.


On Wed, Sep 5, 2012 at 4:43 PM, Jesse Yates <[EMAIL PROTECTED]> wrote:
> On Wed, Sep 5, 2012 at 3:58 PM, Elliott Clark <[EMAIL PROTECTED]>wrote:
>> +1 on git, either on github or closer to the linux model with real
>> distributed repos.
>> - I've been using it for just about all of my development and it works
>> pretty nicely.  I push everything to github as I'm working.  Then I
>> squash commits and create a diff to post on jira.
> I do the same, just locally. Solid model.
>> - I would suggest that since hbase's code base moves so rapidly, a
>> rebased branch should probably be a requirement before merging.
>> Otherwise the merge will get pretty interesting for very long lived
>> branches.
> IIRC when Todd was working on some large stuff for HDFS he was doing this
> in a feature branch every few days. Seriously helps with when things are
> actually finished in terms of rolling it back in.
> Using github to keep a constantly rebased version (every few days) would be
> a reasonble, super-low friction way of solving the problem for
> non-committers. Further, for big changes, it would ensure that if the
> people go away we aren't left with a bunch of dangling branches in the svn.
> Problem here is also establishing the 'master' branch in github, though
> that can be established on a case-by-case basis with the people involved.
>> On Wed, Sep 5, 2012 at 11:38 AM, Jonathan Hsieh <[EMAIL PROTECTED]> wrote:
>> > This has been brought up in the past but we are here again.
>> >
>> > We have a few large features that are hanging out and having a hard time
>> > because trunk changes underneath it and in some cases because they are
>> > being worked by folks without a commit bit.   (ex: snapshots w/ Jesse and
>> > Matteo, and have some other potentially in the pipeline -- major
>> assignment
> I'm generally opposed to doing feature branches for a variety of reasons
> (left behind functionality, hard to roll back in, difficulty of testing,
> etc) and further don't really feel its really necessary for the snapshot
> code given that the code doesn't touch all that much of the current
> codebase.
> A lot of the pain with it right now is that the code has been broken into 5
> patches, making it hard to build a version of HBase that has snapshots 'in
> its current form'. This gets even worse as I'm planning on doing a bit more
> refactoring into a couple more patches to help make it more digestable
> (e.g. see latest patch for 3PC https://reviews.apache.org/r/6592/ which
> pulls out a lot of the coordination functionality)). This helps with
> reviews, etc, but makes it a bit of a pain for people who want to do
> advanced testing on the feature - hard to justify doing a lot of that work
> though as if the code is changing a lot, then testing doesn't make much
> sense.
> In terms of how the work is breaking down, with Matteo doing restore on top
> of the taking that I'm working on, his part clearly depends on the taking
> of snapshots. However, the filesystem layout hasn't changed at all in
> nearly the last two months, meaning the work can proceed pretty much
> independently (more or less).
>> > manager changes with Jimmy and possibly me,
> This is a lot more high-touch with the codebase, making a branch (either in
> sandbox or otherwise) more feasible.
>>  HBASE-4120, HBASE-2600,
>> > removing root)
> Salesforce is planning on tackling at least the latter two in the next few
> months, so this is something that we need to figure out :)
>>  >
>> > Though I wasn't around yet, it seems like this is what we did for
>> > coprocs/security, probably for the 0.90 master.

Todd Lipcon
Software Engineer, Cloudera