Forwarding on pat's behalf Sent from my iPhone
Begin forwarded message: > From: Pat Ferrel <[email protected]> > Date: March 8, 2014 at 11:48:57 AM EST > To: Suneel Marthi <[email protected]>, Andrew Musselman > <[email protected]> > Subject: Fwd: Light weight process for Examples contributions > > I’ve re-aplied for dev@, confirmed my application, and supposedly been > accepted. But as of this morning seem still unable to send to the list. For > the time being can one of you forward this for me to dev@? > > Thanks. > > Begin forwarded message: > > From: Pat Ferrel <[email protected]> > Subject: Fwd: Light weight process for Examples contributions > Date: March 8, 2014 at 8:27:18 AM PST > To: [email protected] > > Apologies if this is a repeat, I seem to have been dropped from dev@--the > universe trying to tell me something? > > Begin forwarded message: > > From: Pat Ferrel <[email protected]> > Subject: Light weight process for Examples contributions > Date: March 7, 2014 at 2:30:15 PM PST > To: [email protected] > > This suggestion only applies to Mahout-Example code, not for more tightly > integrated patches. > > The method currently used by Mahout for accepting contributions to > Mahout-Examples seems needlessly heavyweight. It also seems to discourage > updating of example code since every tiny bug fix must be resubmitted as a > patch created by hand outside of the normal dev process for the example. > > I have an example to contribute that has it’s own POM and is a completely > self-contained project on github. Those who use github will know the pattern. > If you want to help with the project you fork it, then submit a pull request > which essentially creates a master patch. A single merge of the pull request > accepts the patch and updates the repo. Also you can embed a project inside > your own by merely including the subproject with its own git files. You 'git > clone’ to the right place in the uber project. > > Thereafter the sub-project’s maintainer can make updates independent of the > uber project but every time it is cloned or pulled it will be updated in the > uber-project. > > Imagine creating a manifest text file with links to github repos and > descriptions of the example code then putting it in Mahout-Examples. A user > of Mahout would go to the example directory and do a ‘git clone’ or ‘git pull > origin master’ to get or update the example. In other words fixing a bug in > the contributed code is as easy as fixing it in your own repo. You fix it, > commit it, push it and you are done. > > This would be so much easier for contributors to maintain example code. I > suspect the submit patch mechanism has lead to very few updates to examples, > which in turn means they quickly get out of date and are easy to abandon. > > This method would remove the need to have the examples published as artifacts > in Maven-land or maintained in builds by the Mahout team. > > The Examples directory would simply be a text manifest of examples, which > could each be cloned and built on demand. The manifest would be the only > thing “patched” and therefore would be still completely controlled by the > committers but in a very easy way for both parties to maintain. Committers > can check the Examples manifest and the linked code to remove zombies or > strayed projects at will. > > I understand that there are concerns about licensing and copyrights but > believe this bypasses those issues since no code is actually being included > in Mahout and no external code is being built and distributed with mahout > artifacts. In any case licensing can still use an Apache license and > copyrights can still be granted to Apache if needed. > > I have a fairly complex example that has several options. Not all are fully > implemented or tested. Therefore I’ll be making frequent changes to it and > have already accepted one pull request on github. Following the above method > would make the flow for getting the fixes into Examples much much easier and > isolate Apache from any liabilities implied or otherwise. > > This methodology fits much more the github way, which is why it’s becoming so > popular--widely considered to be a better collaboration platform. If you read > the announcement of better github support from the Apache Infra group it > concedes to this fact and supports tighter github integration. > > If this is reasonable I can create a Jira describing the manifest, a commiter > can accept my patch—the seed manifest with my example. Before it is accepted > the committer can request any changes to the project since it is already > published and cloneable. Or they can fork my repo and make changes > required—as they wish. Then I’ll accept the pull request, etc. This should be > super easy for any committer familiar with github and I notice that most use > it for their own experiments. > > Should I create a Jira for this? > > > >
