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


Copy link to this message
-
Re: Thoughts about large feature dev branches
On Wed, Sep 5, 2012 at 3:49 PM, Stack <[EMAIL PROTECTED]> wrote:

> On Wed, Sep 5, 2012 at 11:38 AM, Jonathan Hsieh <[EMAIL PROTECTED]>
> wrote:> Where the folks working on those features committers at the time?
>  What do
> > we do for contributions from folks who aren't committers yet?
> >
>
> Yes.
>
> For folks not yet committers, lets look at them.  If they are working
> on big features for HBase, they probably should be committers?
>
> This is probably case by case.
> > 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
>
> Do you mean github when you say git above?  So their work is
> accessible by others?
>
> Yes, github.  Personally, I'm not familiar with github's review interface
and prefer doing reviews on reviewboard.  Fewer systems for me to figure
out, and fewer places for me to look. :)
> > 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.
> >
>
> Your proposal looks great to me.
>
> > 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.
> >
>
> We could do this but more overhead that your first suggestion.
>
> I agree this is more work but svn is harder to change and feels more
"official".  I guess this is part of the apache legacy.
> Good on you Jon,
> St.Ack
>

--
// Jonathan Hsieh (shay)
// Software Engineer, Cloudera
// [EMAIL PROTECTED]
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