You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@mahout.apache.org by Sean Owen <sr...@gmail.com> on 2009/07/28 18:44:52 UTC

Reminder: big collaborative filtering change in MAHOUT-151

https://issues.apache.org/jira/browse/MAHOUT-151

I have just attached my first cut at a patch, and it is massive
indeed. This one removes "User", and along the way, attempts to remove
some of the "Boolean" classes as they can kind of be rolled into the
primary implementation.

It compiles, it passes tests. I am still not done digging through the
performance implications. Comments welcome.

I wanted to spam the list again since this will probably break many
user's implementations; it's not backwards-compatible. I also want to
warn that, given the scale of the change, there could be new bugs, and
could be new performance implications which will take a little time to
work through. If you're concerned about this, don't update past the
code as it exists in SVN right now, for a while.

Re: Reminder: big collaborative filtering change in MAHOUT-151

Posted by zaki rahaman <za...@gmail.com>.
I think it should, and it's probably for the better if this gets done before
the listserv is flooded by reports of broken functionality.

On Tue, Jul 28, 2009 at 4:41 PM, Ted Dunning <te...@gmail.com> wrote:

> Should this be a branch?
>
> On Tue, Jul 28, 2009 at 9:44 AM, Sean Owen <sr...@gmail.com> wrote:
>
> > https://issues.apache.org/jira/browse/MAHOUT-151
> >
> > I have just attached my first cut at a patch, and it is massive
> > indeed. This one removes "User", and along the way, attempts to remove
> > some of the "Boolean" classes as they can kind of be rolled into the
> > primary implementation.
> >
> > It compiles, it passes tests. I am still not done digging through the
> > performance implications. Comments welcome.
> >
> > I wanted to spam the list again since this will probably break many
> > user's implementations; it's not backwards-compatible. I also want to
> > warn that, given the scale of the change, there could be new bugs, and
> > could be new performance implications which will take a little time to
> > work through. If you're concerned about this, don't update past the
> > code as it exists in SVN right now, for a while.
> >
>
>
>
> --
> Ted Dunning, CTO
> DeepDyve
>



-- 
Zaki Rahaman

Re: R: R: Reminder: big collaborative filtering change in MAHOUT-151

Posted by Sean Owen <sr...@gmail.com>.
Don't use github -- that is not the official repository and may not be
up to date. I don't know why it's there. You want
http://svn.apache.org/repos/asf/lucene/mahout/trunk

This is a function of Subversion rather than something particular to
Mahout. On the command line, if I recall rightly, you would use "svn
update -r 797486" to sync to that revision. In an IDE, I imagine there
would similarly be some function to sync to a revision. I know there
is in IntelliJ.

On Wed, Jul 29, 2009 at 9:27 AM, Claudia Grieco<gr...@crmpa.unisa.it> wrote:
>> Since the change for MAHOUT-149 and MAHOUT-150 was in revision 797487,
>>I would simply sync to 797486.
> How? I consulted the trunk at http://github.com/apache/mahout/tree/trunk and there's only the latest version of the code. Where are these revisions stored?

R: R: Reminder: big collaborative filtering change in MAHOUT-151

Posted by Claudia Grieco <gr...@crmpa.unisa.it>.
> Since the change for MAHOUT-149 and MAHOUT-150 was in revision 797487,
>I would simply sync to 797486.
How? I consulted the trunk at http://github.com/apache/mahout/tree/trunk and there's only the latest version of the code. Where are these revisions stored?

-----Messaggio originale-----
Da: Sean Owen [mailto:srowen@gmail.com] 
Inviato: mercoledì 29 luglio 2009 10.22
A: mahout-user@lucene.apache.org
Oggetto: Re: R: Reminder: big collaborative filtering change in MAHOUT-151

Since the change for MAHOUT-149 and MAHOUT-150 was in revision 797487,
I would simply sync to 797486. You will get some improvements since
0.1 but not the major changes (although the MAHOUT-149/150 change
wasn't so big for callers, and offers memory improvements)

On Wed, Jul 29, 2009 at 8:44 AM, Claudia Grieco<gr...@crmpa.unisa.it> wrote:
> Where can I obtain a patch for all the changes prior to this version? (also prior to mahout-150 that starts to remove the concept of items)
> I'm currently using the released version 0.1


Re: R: Reminder: big collaborative filtering change in MAHOUT-151

Posted by Sean Owen <sr...@gmail.com>.
Since the change for MAHOUT-149 and MAHOUT-150 was in revision 797487,
I would simply sync to 797486. You will get some improvements since
0.1 but not the major changes (although the MAHOUT-149/150 change
wasn't so big for callers, and offers memory improvements)

On Wed, Jul 29, 2009 at 8:44 AM, Claudia Grieco<gr...@crmpa.unisa.it> wrote:
> Where can I obtain a patch for all the changes prior to this version? (also prior to mahout-150 that starts to remove the concept of items)
> I'm currently using the released version 0.1

R: Reminder: big collaborative filtering change in MAHOUT-151

Posted by Claudia Grieco <gr...@crmpa.unisa.it>.
Where can I obtain a patch for all the changes prior to this version? (also prior to mahout-150 that starts to remove the concept of items)
I'm currently using the released version 0.1

-----Messaggio originale-----
Da: Sean Owen [mailto:srowen@gmail.com] 
Inviato: martedì 28 luglio 2009 23.04
A: mahout-user@lucene.apache.org
Oggetto: Re: Reminder: big collaborative filtering change in MAHOUT-151

I'm into that. What's the ideal relation between branches and
releases? So I put this in a branch, work on it for a bit, then
re-integrate before 0.2? I don't want to be disruptive but also want
to take advantage of the flexibility we have in the early stages of
the project to push big change into the main branch quickly.

On Tue, Jul 28, 2009 at 9:41 PM, Ted Dunning<te...@gmail.com> wrote:
> Should this be a branch?
>


Re: Reminder: big collaborative filtering change in MAHOUT-151

Posted by Grant Ingersoll <gs...@apache.org>.
In the past, Lucene has always pushed patches, but I know I've argued  
for branches too.  Either way, you end up doing work to merge.   
Personally, I feel so comfortable with patches these days that I  
rarely think of branching, but that isn't to say it is wrong or that  
someone else prefers that way.  While I like to keep trunk working,  
etc. no one says it has to be perfect, so if you feel something is  
ready to commit, then do so.  You're more likely to get more eyeballs  
on trunk than on a branch, I think, and as long as it is worked out by  
the next release, I don't know if it matters.


On Jul 28, 2009, at 6:15 PM, Ted Dunning wrote:

> Grant is the process meister here, but what you say is close.
>
> On Tue, Jul 28, 2009 at 2:03 PM, Sean Owen <sr...@gmail.com> wrote:
>
>> I'm into that. What's the ideal relation between branches and
>> releases? So I put this in a branch, work on it for a bit, then
>> re-integrate before 0.2? I don't want to be disruptive but also want
>> to take advantage of the flexibility we have in the early stages of
>> the project to push big change into the main branch quickly.
>>
>> On Tue, Jul 28, 2009 at 9:41 PM, Ted Dunning<te...@gmail.com>  
>> wrote:
>>> Should this be a branch?
>>>
>>
>
>
>
> -- 
> Ted Dunning, CTO
> DeepDyve



Re: Reminder: big collaborative filtering change in MAHOUT-151

Posted by Ted Dunning <te...@gmail.com>.
Grant is the process meister here, but what you say is close.

On Tue, Jul 28, 2009 at 2:03 PM, Sean Owen <sr...@gmail.com> wrote:

> I'm into that. What's the ideal relation between branches and
> releases? So I put this in a branch, work on it for a bit, then
> re-integrate before 0.2? I don't want to be disruptive but also want
> to take advantage of the flexibility we have in the early stages of
> the project to push big change into the main branch quickly.
>
> On Tue, Jul 28, 2009 at 9:41 PM, Ted Dunning<te...@gmail.com> wrote:
> > Should this be a branch?
> >
>



-- 
Ted Dunning, CTO
DeepDyve

Re: Reminder: big collaborative filtering change in MAHOUT-151

Posted by Sean Owen <sr...@gmail.com>.
I'm into that. What's the ideal relation between branches and
releases? So I put this in a branch, work on it for a bit, then
re-integrate before 0.2? I don't want to be disruptive but also want
to take advantage of the flexibility we have in the early stages of
the project to push big change into the main branch quickly.

On Tue, Jul 28, 2009 at 9:41 PM, Ted Dunning<te...@gmail.com> wrote:
> Should this be a branch?
>

Re: Reminder: big collaborative filtering change in MAHOUT-151

Posted by Ted Dunning <te...@gmail.com>.
Should this be a branch?

On Tue, Jul 28, 2009 at 9:44 AM, Sean Owen <sr...@gmail.com> wrote:

> https://issues.apache.org/jira/browse/MAHOUT-151
>
> I have just attached my first cut at a patch, and it is massive
> indeed. This one removes "User", and along the way, attempts to remove
> some of the "Boolean" classes as they can kind of be rolled into the
> primary implementation.
>
> It compiles, it passes tests. I am still not done digging through the
> performance implications. Comments welcome.
>
> I wanted to spam the list again since this will probably break many
> user's implementations; it's not backwards-compatible. I also want to
> warn that, given the scale of the change, there could be new bugs, and
> could be new performance implications which will take a little time to
> work through. If you're concerned about this, don't update past the
> code as it exists in SVN right now, for a while.
>



-- 
Ted Dunning, CTO
DeepDyve