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 >> Thoughts about large feature dev branches


Copy link to this message
-
Re: Thoughts about large feature dev branches
+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 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.

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
> manager changes with Jimmy and possibly me, HBASE-4120, HBASE-2600,
> removing root)
>
> Though I wasn't around yet, it seems like this is what we did for
> coprocs/security, probably for the 0.90 master.
> http://search-hadoop.com/m/byzZYZMktx1/hbase+windows&subj=Re+Proposed+feature+branch+for+HBase+security
>
> Where the folks working on those features committers at the time?  What do
> we do for contributions from folks who aren't committers yet?
>
> This was proposed over on hadoop-general by Todd -- what do you all think
> about doing something like this for the major changes?  (Github seems
> easiest, svn seems "more official").
>
> Here's one proposal, making use of git as an easy way to allow
> non-committers to "commit" code while still tracking development in
> the usual places:
> - Upon anyone's request, we create a new "Version" tag in JIRA.
> - The developers create an umbrella JIRA for the project, and file the
> individual work items as subtasks (either up front, or as they are
> developed if using a more iterative model)
> - On the umbrella, they add a pointer to a git branch to be used as
> the staging area for the branch. As they develop each subtask, they
> can use the JIRA to discuss the development like they would with a
> normally committed JIRA, but when they feel it is ready to go (not
> requiring a +1 from any committer) they commit to their git branch
> instead of the SVN repo.
> - When the branch is ready to merge, they can call a merge vote, which
> requires +1 from 3 committers, same as a branch being proposed by an
> existing committer. A committer would then use git-svn to merge their
> branch commit-by-commit, or if it is less extensive, simply generate a
> single big patch to commit into SVN.
>
> My thinking is that this would provide a low-friction way for people
> to collaborate with the community and develop in the open, without
> having to work closely with any committer to review every individual
> subtask.
>
> Another alternative, if people are reluctant to use git, would be to
> add a "sandbox/" repository inside our SVN, and hand out commit bit to
> branches inside there without any PMC vote. Anyone interested in
> contributing could request a branch in the sandbox, and be granted
> access as soon as they get an apache SVN account.
>
>
>
> --
> // Jonathan Hsieh (shay)
> // Software Engineer, Cloudera
> // [EMAIL PROTECTED]
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