I like this idea.
> On Mar 8, 2014, at 9:09 AM, Suneel Marthi <[email protected]> wrote: > > 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? >> >> >> >>
