hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Elliott Clark <ecl...@stumbleupon.com>
Subject Re: Thoughts about large feature dev branches
Date Wed, 05 Sep 2012 22:58:08 GMT
+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

On Wed, Sep 5, 2012 at 11:38 AM, Jonathan Hsieh <jon@cloudera.com> 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
> // jon@cloudera.com

View raw message