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
Todd Lipcon 2012-09-05, 23:48
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:
https://github.com/mirrors/linux-2.6/blob/master/Documentation/SubmittingPatches

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

-Todd

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