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
+
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
Copy link to this message
-
Re: Thoughts about large feature dev branches
On Wed, Sep 5, 2012 at 11:38 AM, Jonathan Hsieh <[EMAIL PROTECTED]> wrote:
> 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

Though we had multiple contributors, not all committers, I could have
committed any of the work at any time and Gary soon was a committer as well.

> 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:
> [...]
> 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.

I use git and private GitHub repos for all of our distribution engineering
work so personally this gets a big +1 from me. This is how we are operating
internally.

For example, I've been following along with Todd's HDFS-3077 feature
development locally as a patch series floating on branch-2, via cherry-pick
of the changes and periodic rebase of those picks against the branch. It
would be, personally, trivial to cherry pick from any git repo, does not
have to be git.apache.org (in this case HDFS-3077 work is on a feature
branch in Apache SVN). This has been very helpful, it has allowed us to do
some advance testing of this feature under development sufficient to
understand and validate its theory of operation.

It would be excellent to have the option to do something like that with
other works under development by those who might not have Apache SVN commit
privs. On the other hand, this takes some effort, with rebasing over an
evolving source you will have to deal with a constant stream of small merge
conflicts, and as time goes on the conflicts will become more significant.
This maintenance effort is to be taken up by the contributor? That's
currently the story of my life (but for ~10 projects, not 1) so I have the
time/patience and I'd like to think skill to deal with it. I also trust the
skill of HBase committers to do this. That does not generalize, though. To
summarize, I think this could work well if orgs like Salesforce put a small
team on a particular task, so I'm all for it, but let's leave it at that
and see how it goes.

Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
+
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