[
https://issues.apache.org/jira/browse/MAHOUT-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12844392#action_12844392
]
Kay Kay commented on MAHOUT-332:
{quote}
must explore SQL and NOSQL implementations, and de
Thanks for helping with the traction of this. This will be greatly
useful to hbase community / users of hadoop in general.
On 03/11/2010 04:45 AM, Drew Farris wrote:
Hadoop team. Chris pushed it to the report yesterday evening.
Drew
On Mar 11, 2010 1:54 AM, "Kay Kay" wrote:
Out of curiosity
[
https://issues.apache.org/jira/browse/MAHOUT-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robin Anil updated MAHOUT-333:
--
Description:
A student with a good proposal
- should be free to work for Mahout in the summer and shou
Implement a visualization tool to help a user visualize the output of
clustering and other algorithms
-
Key: MAHOUT-333
URL: https://issues.apache.org/jira/browse/
Create adapters for MYSQL and NOSQL(hbase, cassandra) to access data for all
the algorithms to use
---
Key: MAHOUT-332
URL: https://issues.apache.org/jira/browse/MAHO
Continuous performance benchmarking/dashboard w/ wrappers over EC2
--
Key: MAHOUT-331
URL: https://issues.apache.org/jira/browse/MAHOUT-331
Project: Mahout
Issue Type: New Featu
Implement a meta-learner over the different classifiers in mahout
-
Key: MAHOUT-330
URL: https://issues.apache.org/jira/browse/MAHOUT-330
Project: Mahout
Issue Type: New Feature
Implement some recommendation ideas used by the Netflix top teams to boost the
recommenders package
---
Key: MAHOUT-329
URL: https://issues.apache.org/jira/browse/MAHO
Implement a cool clustering algorithm on map/reduce
---
Key: MAHOUT-328
URL: https://issues.apache.org/jira/browse/MAHOUT-328
Project: Mahout
Issue Type: New Feature
Components: Clust
Implement a cool classifier over map/reduce
---
Key: MAHOUT-327
URL: https://issues.apache.org/jira/browse/MAHOUT-327
Project: Mahout
Issue Type: New Feature
Components: Classification
Shall I go and put some of the ideas up. I will do it as a whole for the
project. Later we can re-assign things maybe ? How does that sound? Unlike
other projects we cant really go an put a proposal like "Implement
back-propagation" and expect a student to take it up and reduce things to
map/reduce
+1
On Fri, Mar 12, 2010 at 8:02 AM, Drew Farris wrote:
> +1
>
> On Thu, Mar 11, 2010 at 9:24 PM, Jake Mannix
> wrote:
> > Benson for President pro-tempore of Mahout Release!
> >
> > +1
> >
> > On Thu, Mar 11, 2010 at 6:19 PM, Ted Dunning
> wrote:
> >
> >> Should we vote Benson in?
> >>
> >> O
As I understand it, this is a legal formality, not an honor. If you like
I'll go fetch a clarification.
On Thu, Mar 11, 2010 at 9:54 PM, Grant Ingersoll wrote:
>
> On Mar 11, 2010, at 8:04 PM, Benson Margulies wrote:
>
> > I confess that I never quite reproduced srowen's strange behavior.
> Inste
On Mar 11, 2010, at 8:04 PM, Benson Margulies wrote:
> I confess that I never quite reproduced srowen's strange behavior. Instead,
> I applied a few bandaids to the poms to get more predictable behavior:
>
> 1) I made collections depend on collections-codegen, in addition to using
> it, to ensur
I added MAVEN_OPTS on my Mac Pro and all is now good. Kinda surprised it
took so long to bite me. Thanks,
Jeff
and +1 for you as the 0.3 release meister
Benson Margulies wrote:
I rechecked. I did make a tweak to unit test execution, but nothing to
compilation.
You might try co-ing the releas
+1
On Thu, Mar 11, 2010 at 9:24 PM, Jake Mannix wrote:
> Benson for President pro-tempore of Mahout Release!
>
> +1
>
> On Thu, Mar 11, 2010 at 6:19 PM, Ted Dunning wrote:
>
>> Should we vote Benson in?
>>
>> On Thu, Mar 11, 2010 at 5:04 PM, Benson Margulies > >wrote:
>>
>> > 1) Vote someone as
Benson for President pro-tempore of Mahout Release!
+1
On Thu, Mar 11, 2010 at 6:19 PM, Ted Dunning wrote:
> Should we vote Benson in?
>
> On Thu, Mar 11, 2010 at 5:04 PM, Benson Margulies >wrote:
>
> > 1) Vote someone as release manager. This shifts liability from the person
> > to
> > the fo
Should we vote Benson in?
On Thu, Mar 11, 2010 at 5:04 PM, Benson Margulies wrote:
> 1) Vote someone as release manager. This shifts liability from the person
> to
> the foundation in the event of some complaint.
> 2) Prepare the release.
> 3) Vote the release.
>
> Not all projects seem to make a
Proposed Mahout release 0.3 artifacts can by found at:
https://repository.apache.org/content/repositories/orgapachemahout-005/
A report of issues addressed in this release can be found at
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=12310751&status=5&status=6&fixfor=
This time someone from #asfinfra sacrificed a chicken. Or something. Or
someone.
Well, the nexus server doesn't like the gpg signatures. I used the right
version of maven. Maybe my key needs to be uploaded? I'm looking.
I rechecked. I did make a tweak to unit test execution, but nothing to
compilation.
You might try co-ing the release tag and building that, just for yucks. Or
change -Xmx in your MAVEN_OPTS and see if that's enough.
On Thu, Mar 11, 2010 at 8:19 PM, Jeff Eastman wrote:
> Benson Margulies wrote:
Benson Margulies wrote:
Did you get the number of that commit? The very last commit was my release
arranging, and it's pretty hard to see how it could have that effect.
On Thu, Mar 11, 2010 at 7:54 PM, Jeff Eastman wrote:
I'm getting a consistent compiler heap overflow during mvn clean inst
Benson Margulies wrote:
Did you get the number of that commit? The very last commit was my release
arranging, and it's pretty hard to see how it could have that effect.
On Thu, Mar 11, 2010 at 7:54 PM, Jeff Eastman wrote:
I'm getting a consistent compiler heap overflow during mvn clean inst
Did you get the number of that commit? The very last commit was my release
arranging, and it's pretty hard to see how it could have that effect.
On Thu, Mar 11, 2010 at 7:54 PM, Jeff Eastman wrote:
> I'm getting a consistent compiler heap overflow during mvn clean install on
> one of two machines
I confess that I never quite reproduced srowen's strange behavior. Instead,
I applied a few bandaids to the poms to get more predictable behavior:
1) I made collections depend on collections-codegen, in addition to using
it, to ensure that the reactor would process the former before the later.
2)
Yes. Sorry, I meant to send a status report first. Coming right up.
On Thu, Mar 11, 2010 at 7:55 PM, Grant Ingersoll wrote:
> Shall we assume by your vote call that this was fixed?
>
> On Mar 11, 2010, at 5:28 PM, Benson Margulies wrote:
>
> > OK, I see something. I'm trying to use -Dmaven.test.s
So, I got the release process to go. I would like to propose a slight
rearrangement to match patterns I've seen elsewhere.
a) Make a new directory, distribution. Put the assembly executions and such
in there.
b) get rid of the maven directory. Move the contents of that pom into the
toplevel pom.
c
Shall we assume by your vote call that this was fixed?
On Mar 11, 2010, at 5:28 PM, Benson Margulies wrote:
> OK, I see something. I'm trying to use -Dmaven.test.skip=true to speed
> things up, but that stops the creation of the test jar. Unfortunately, since
> I get random test failures, this is
I'm getting a consistent compiler heap overflow during mvn clean install
on one of two machines with the last commit. Ironically, my MacBook Pro
compiles and my Mac Pro does not. Both compiled before the commit.
I know Robin was interested in mentoring. Grant possibly as well. I think
that I will only be able to meta-mentor due to other commitments.
In any case, this message is important if you want to be a mentor.
-- Forwarded message --
From: Ross Gardler
Date: Thu, Mar 11, 2010 at 4
The release pieces for Mahout are available at the nexus staging repository
for Mahout:
https://repository.apache.org/service/local/staging/deploy/maven2/
This vote will be open for 72 hours.
Note that I am not a legally designated release manager, but perhaps the PMC
would care to take that vo
OK, I see something. I'm trying to use -Dmaven.test.skip=true to speed
things up, but that stops the creation of the test jar. Unfortunately, since
I get random test failures, this is a problem.
I think that we need to replace the test-jar trick with an extra project,
since it's really preferably
>
> I have problems before you have problems. I can't build mahout-utils at
> all. I'm looking into it. This is with no funny profiles.
>
[INFO] Building Mahout Utilities
[INFO]task-segment: [install]
[INFO]
Downloading:
On Mar 11, 2010, at 8:58 AM, Benson Margulies wrote:
> Sean,
>
> I'll refresh my memory, but I didn't think it build from the tag until the
> perform step.
>
> I have to go pretend to work for a living for the next hours, but thereafter
> I'll take this and run with it.
>
> I don't know if I h
Sean,
I'll refresh my memory, but I didn't think it build from the tag until the
perform step.
I have to go pretend to work for a living for the next hours, but thereafter
I'll take this and run with it.
I don't know if I have credentials to push to nexus, but if I get that far
we'll be doing we
I've done a full rebuild once or twice here with various different
approaches and see the same thing.
It does seem to do everything you say except check in. I kind of
thought it would be doing this:
- Mark stuff as version 0.3
- Tag, etc.
- Build and install 0.3 of everything
- Commit
So yeah I
Guys,
Here's now to diagnose this.
release:prepare:
a) runs an ordinary build which should succeed.
b) edits the poms to remove the -SNAPSHOTS.
c) checks them in.
d) makes a tag.
e) puts the new snapshots in the poms.
f) checks them in.
I don't see a tag. So I don't understand how you got to be
Here's mine from last time:
mahout_release
XX
mahout.releases::default::
https://repository.apache.org/service/local/staging/deploy/maven2/
gsingers
gsingers
https://repository.apache.org/service/local/staging/deploy/maven2/
The only SNAPSHOT reference I see in maven/pom.xml is the project
version of 0.3-SNAPSHOT, which gets updated during release.
At some point it asks me what the release version should be and next
dev version -- I say 0.3 and 0.4-SNAPSHOT, right?
This is my settings.xml -- don't see anything obvio
Or the version didn't get set to non-SNAPSHOT in the plugin's pom?
On Thu, Mar 11, 2010 at 7:05 AM, Sean Owen wrote:
> Ah just the mvn -Prelease,mahout_release release:prepare business
>
> On Thu, Mar 11, 2010 at 12:02 PM, Grant Ingersoll
> wrote:
> > What were you running when you hit this?
>
Somehow, your release build is refusing to find and use the collection code
generator plugin -- that it just built.
Is the for it somehow disabled in the release profile?
On Thu, Mar 11, 2010 at 7:05 AM, Sean Owen wrote:
> Ah just the mvn -Prelease,mahout_release release:prepare business
>
>
Hadoop team. Chris pushed it to the report yesterday evening.
Drew
On Mar 11, 2010 1:54 AM, "Kay Kay" wrote:
Out of curiosity - is the 0.20.2 (hadoop ) released by the hadoop team or
the mahout team ?
On 03/10/2010 02:33 PM, Drew Farris (JIRA) wrote:
>
> [ https://issues.apache.org/ji
Ah just the mvn -Prelease,mahout_release release:prepare business
On Thu, Mar 11, 2010 at 12:02 PM, Grant Ingersoll wrote:
> What were you running when you hit this?
What were you running when you hit this?
On Mar 11, 2010, at 5:52 AM, Sean Owen wrote:
> OK, next snag. Can anyone interpret this?
>
> [INFO] [INFO] Building jar:
> /Users/srowen/Documents/Development/Mahout/collections/target/mahout-collections-0.3.jar
> [INFO] [INFO] Preparing source:jar
> [IN
Yeah I change the hashCode() to match equals() in this case since
equals() takes account of length.
On Thu, Mar 11, 2010 at 10:20 AM, Robin Anil wrote:
> Nevermind. This is not even the issue :)
>
> Robin
OK, next snag. Can anyone interpret this?
[INFO] [INFO] Building jar:
/Users/srowen/Documents/Development/Mahout/collections/target/mahout-collections-0.3.jar
[INFO] [INFO] Preparing source:jar
[INFO] Downloading:
http://repo1.maven.org/maven2/org/apache/mahout/mahout-collection-codegen-plugin/0.3
Nevermind. This is not even the issue :)
Robin
On Thu, Mar 11, 2010 at 3:46 PM, Robin Anil wrote:
> Found the error. Its in the hashCode function for pattern.
>
> This causes erroneous execution.
> int result = Arrays.hashCode(pattern);
> result = 31 * result + RandomUtils.hashLong(suppo
Found the error. Its in the hashCode function for pattern.
This causes erroneous execution.
int result = Arrays.hashCode(pattern);
result = 31 * result + RandomUtils.hashLong(support);
result = 31 * result + length;
So does this
int result = Arrays.hashCode(pattern);
result = 3
The FPM output is incorrect. I will have to see what broke.
Robin
On Thu, Mar 11, 2010 at 2:56 PM, wrote:
> Author: srowen
> Date: Thu Mar 11 09:26:39 2010
> New Revision: 921751
>
> URL: http://svn.apache.org/viewvc?rev=921751&view=rev
> Log:
> Last round of streamlining/style suggestions for
Looks like we're clear. I'm going to start the release process again.
On Thu, Mar 11, 2010 at 3:20 AM, Drew Farris wrote:
> Looks like the hadoop 0.20.2 issue is finally put to bed -- any other
> issues that we need to resolve before we proceed with a release?
>
51 matches
Mail list logo
