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

Switch to Plain View
HBase, mail # dev - Thoughts about large feature dev branches


+
Jonathan Hsieh 2012-09-05, 18:38
Copy link to this message
-
Re: Thoughts about large feature dev branches
Elliott Clark 2012-09-05, 22:58
+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]
+
Jesse Yates 2012-09-05, 23:43
+
Todd Lipcon 2012-09-05, 23:48
+
Jonathan Hsieh 2012-09-06, 11:08
+
Stack 2012-09-05, 22:49
+
Jonathan Hsieh 2012-09-06, 10:33
+
Stack 2012-09-06, 19:44
+
Andrew Purtell 2012-09-06, 14:03
+
Dave Wang 2012-09-12, 06:49
+
Andrew Purtell 2012-09-12, 07:24
+
lars hofhansl 2012-09-12, 20:42
+
Stack 2012-09-13, 04:55
+
Stack 2012-09-12, 18:28
+
Andrew Purtell 2012-09-12, 18:43
+
Stack 2012-09-12, 19:21