Hello, Shall we move forward with this proposal? Let's get this in place soon so larger projects such as snapshots can make use of this.
- Dave On Wed, Sep 5, 2012 at 11:38 AM, Jonathan Hsieh <[email protected]> wrote: > 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] >
