That's fine, I was talking about the non-distributed part only.

This page has instructions on how to create patches:

https://mahout.apache.org/developers/how-to-contribute.html

Let me know if you need more infos!

Best,
Sebastian


On 03/05/2014 12:27 AM, Mario Levitin wrote:
I have created a Jira issue already.
I only use the non-hadoop part of Mahout recommender algorithms.
May be I can create a patch for that part. However, I have not done it
before, and don't know how to proceed.


On Wed, Mar 5, 2014 at 1:01 AM, Sebastian Schelter <s...@apache.org> wrote:

Would you be willing to set up a jira issue and create a patch for this?

--sebastian


On 03/04/2014 11:58 PM, Mario Levitin wrote:


I think we should introduce a new parameter for the recommend() method in
the Recommender interface that tells whether already known items should
be
recommended or not.



I agree (if the parameter is missing then defaults to current behavior as
Pat suggested)





On 03/04/2014 05:32 PM, Pat Ferrel wrote:


  I'd suggest a command line option if you want to submit a patch. Most
people will want that line executed so the default should be the current
behavior. But a large minority will want it your way.

And please do submit a patch with the Jira, it will make your life
easier
when new releases come out you won't have to manage a fork.

On Mar 2, 2014, at 12:38 PM, Mario Levitin <mariolevi...@gmail.com>
wrote:

Juan, I don't understand your solution, if there are no ratings how can
you
blend the recommendations from the system and the user's already read
news.

Anyway, I think, as Pat does, the best way is to remove the mentioned
line.
It should be the responsibility of the business logic to remove user's
items if needed.

I will also create a Jira issue as you suggested.

thanks
On Sun, Mar 2, 2014 at 7:12 PM, Ted Dunning <ted.dunn...@gmail.com>
wrote:

   On Sun, Mar 2, 2014 at 8:52 AM, Pat Ferrel <p...@occamsmachete.com>

wrote:

   You are not the only one to see this so I'd recommend creating an
option

for the Job, which will be checked before executing that line of code

  then

  submit it as a patch to the Jira you need to create in any case.

That way it might get into the mainline and you won't have to
maintain a
fork.


  Avoiding the cost of a fork over a trivial issue like this is a grand
idea.









Reply via email to