Jonathan Hsieh 2012-09-05, 18:38
+1 on git, either on github or closer to the linux model with real
- 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 <[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.
> 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
> 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