hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Hsieh <...@cloudera.com>
Subject Re: Thoughts about large feature dev branches
Date Thu, 06 Sep 2012 10:33:02 GMT
On Wed, Sep 5, 2012 at 3:49 PM, Stack <stack@duboce.net> wrote:

> On Wed, Sep 5, 2012 at 11:38 AM, Jonathan Hsieh <jon@cloudera.com>
> 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
// jon@cloudera.com

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message