+1 from me as well. Non-MR patches are a starting point for MR ideas anyway.
I've been terribly busy, so I couldn't contribute so far -- really sorry about
it. Good work on the clustering algorithms, Jeff! I'll reserve some time on
Wednesday to go through the code and see if I can add something of value.
Dawid
Otis Gospodnetic wrote:
Definitely +1 (even) for non-MR patches.
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
----- Original Message ----
From: Grant Ingersoll <[EMAIL PROTECTED]>
To: [email protected]
Sent: Thursday, February 14, 2008 3:57:33 PM
Subject: Re: Community development was Re: [jira] Updated: (MAHOUT-4) Simple
prototype for Expectation Maximization (EM)
Right, the question is more along the lines of would people rather see
patches committed even if they aren't in M/R form? It is a given in
my mind that at a minimum they have to compile and have reasonable
unit tests, etc. Taking this approach would allow people to put up
initial standard patches, and then give others room to improve
separately with M/R implementations, etc.
Just trying to get at what people will find the most useful for
getting code that people can work on, extend, etc.
-Grant
On Feb 14, 2008, at 3:20 PM, Ted Dunning wrote:
Patches should be for the continuous integration system and for the
committers, not normally for users to use for building the code. They
should either download a release or they should download the trunk.
On 2/14/08 6:58 AM, "Goel, Ankur" wrote:
This brings up an ... find patches?
My vote is in favour having people check-out code directly instead of
finding patches.
