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 Plain View
HBase >> mail # dev >> Thoughts about large feature dev branches


Copy link to this message
-
Thoughts about large feature dev branches
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]
+
Elliott Clark 2012-09-05, 22:58
+
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
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