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
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]
+
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