Re: Hi ... need some help?

[Stevo Slavić]

Disclaimer: I'm not active Mahout maintainer for quite a while, have some
historical perspective, take it with a grain of salt, could be I'm missing
the whole point you were approached for by a wide margin of error.

At a point Mahout, some of its modules, have turned into a scala
library, and there was need to cross publish those modules, across
different scala versions. Back than Maven scala plugin didn't support cross
publishing, it doesn't fit well with Maven's build lifecycle concept
(multiple compile phases - one for each scala version, and what not would
be needed). Switching to sbt could have solved the problem. Switch was
deemed to be too big task, even though ages have been spent on trying to
apply Maven (profiles) + bash scripts and what not to solve the problem.
Trying to apply same approach over and over again and expecting different
results is not smart, no expert can help there. Mahout maintainers and
contributors, should consider alternative approach, one of them being
switching to sbt - it's scala native, supports scala cross publishing,
supports publishing Maven compatible release metadata and binaries.

Kind regards,
Stevo Slavic.

On Thu, Apr 16, 2020 at 9:15 AM Christofer Dutz 
wrote:

> Hi folks,
>
> my name is Chris and I’m involved in quite a lot of Apache projects.
> Justin approached me this morning, asking me if I could perhaps help you.
> He told me you were having trouble with doing Maven releases.
>
> As Maven releases are my specialty, could you please summarize the issues
> you are having?
>
> Chris
>

Re: [VOTE] Apache Mahout 0.13.0 Release Candidate

[Stevo Slavić]

If I understood problem and goal well:
- module with native code has to be included in the release
-- module version change only and I guess documentation published but
-- excluding every other plugin like compilation, packaging binary/jar etc.
and
-- distribution module should include sources of module with native code too
- it should be possible from sources (git and release sources distribution,
for maintainers and lib users respectively) to build everything including
their own jar of native module for given target architecture.

This is not easy to achieve with Maven.

Kind regards,
Stevo Slavic.

On Thu, Apr 13, 2017 at 4:33 PM, Suneel Marthi  wrote:

> Specifically what's the issue, some profile not kicking in or being
> shadowed ?  i can take a look later tonight.
>
> On Wed, Apr 12, 2017 at 11:10 PM, Andrew Musselman <
> andrew.mussel...@gmail.com> wrote:
>
> > Does anyone know anyone on the Maven project or who understands the fine
> > points of making things like this works?
> >
> > On Wed, Apr 12, 2017 at 8:06 PM Andrew Musselman <
> > andrew.mussel...@gmail.com>
> > wrote:
> >
> > > Okay consider this vote cancelled.
> > >
> > > On Wed, Apr 12, 2017 at 8:02 PM Andrew Palumbo 
> > wrote:
> > >
> > >> The line that I suggested the other day:
> > >>
> > >>
> > >> mvn -Pmahout-release,apache-release,viennacl,hadoop2 release:prepare
> > >> release:perform
> > >>
> > >>
> > >> doesn't seem to have activated the viennacl profile
> > >>
> > >> 
> > >> From: Andrew Palumbo 
> > >> Sent: Wednesday, April 12, 2017 10:58:16 PM
> > >> To: dev@mahout.apache.org
> > >> Subject: Re: [VOTE] Apache Mahout 0.13.0 Release Candidate
> > >>
> > >>
> > >> off the top of my head i dont know if it is a regression.   My guess
> is
> > >> that they were missing before.  I think that this may have something
> to
> > do
> > >> with activating the profile -Pviennacl at release time.
> > >>
> > >> 
> > >> From: Andrew Musselman 
> > >> Sent: Wednesday, April 12, 2017 10:48:13 PM
> > >> To: dev@mahout.apache.org; u...@mahout.apache.org
> > >> Subject: Re: [VOTE] Apache Mahout 0.13.0 Release Candidate
> > >>
> > >> Is it a regression or were they missing before, do you know?
> > >>
> > >> On Wed, Apr 12, 2017 at 7:42 PM Andrew Palumbo 
> > >> wrote:
> > >>
> > >> >
> > >> > It looks like we're missing some jars from the binary distro:
> > >> >
> > >> >
> > >> > bin
> > >> >
> > >> > mahout-integration-0.13.0.jar
> > >> >
> > >> > confmahout-math-0.13.0.jar derby.log
> > >> >  mahout-math-scala_2.10-0.13.0.jar docs
> > >> > mahout-mr-0.13.0.jar examples
> > >> > mahout-mr-0.13.0-job.jar flink
> > >> >  mahout-spark_2.10-0.13.0-dependency-reduced.jar h2o
> > >> >  mahout-spark_2.10-0.13.0.jar lib
> > >> >  metastore_db LICENSE.txt NOTICE.txt
> > >> > mahout-examples-0.13.0.jar  README.md
> > mahout-examples-0.13.0-job.jar
> > >> > viennacl mahout-hdfs-0.13.0.jar  viennacl-omp
> > >> >
> > >> > 
> > >> > From: Andrew Musselman 
> > >> > Sent: Tuesday, April 11, 2017 12:05 PM
> > >> > To: u...@mahout.apache.org; dev@mahout.apache.org
> > >> > Subject: Re: [VOTE] Apache Mahout 0.13.0 Release Candidate
> > >> >
> > >> > I've checked hashes and sigs, and run a build with passing tests for
> > >> > vanilla, viennacl, and viennacl-omp profiles.
> > >> >
> > >> > The spark shell runs the SparseSparseDrmTimer.mscala example in the
> > >> binary
> > >> > build and all three source profiles; I saw the GPU get exercised
> when
> > >> > running the viennacl profile from source, and saw all cores on the
> CPU
> > >> get
> > >> > exercised when running the viennacl-omp profile from source.
> > >> >
> > >> > So far I'm +1 (binding).
> > >> >
> > >> >
> > >> >
> > >> > On Tue, Apr 11, 2017 at 8:55 AM, Andrew Musselman <
> > >> > andrew.mussel...@gmail.com> wrote:
> > >> >
> > >> > > This is the vote for release 0.13.0 of Apache Mahout.
> > >> > >
> > >> > > The vote will be going for at least 72 hours and will be closed on
> > >> > Friday,
> > >> > > April 17th, 2017 or once there are at least 3 PMC +1 binding votes
> > >> > (whichever
> > >> > > occurs earlier).  Please download, test and vote with
> > >> > >
> > >> > > [ ] +1, accept RC as the official 0.13.0 release of Apache Mahout
> > >> > > [ ] +0, I don't care either way,
> > >> > > [ ] -1, do not accept RC as the official 0.13.0 release of Apache
> > >> Mahout,
> > >> > > because...
> > >> > >
> > >> > >
> > >> > > Maven staging repo:
> > >> > >
> > >> > > *
> > >> >
> > >> https://repository.apache.org/content/repositories/
> > orgapachemahout-1042/org/apache/mahout/apache-mahout-
> distribution/0.13.0/
> > >> > > <
> > >> >
> > >> 

Re: Welcome Trevor Grant as a new Mahout Committer

[Stevo Slavić]

Congratulations Trevor, well deserved, welcome to the team!

On Tue, May 24, 2016 at 12:32 PM, Suneel Marthi  wrote:

> Welcome Trevor !!! Kokanee Cheers !!
>
> On Mon, May 23, 2016 at 8:39 PM, Andrew Palumbo 
> wrote:
>
> > In recognition of Trevor Grant's contributions to the Mahout project
> > notably his Zeppelin Integration work, the PMC has invited and is pleased
> > to announce that he has accepted our invitation to join the Mahout
> project
> > as a committer.
> >
> > As is customary, I will leave it to Trevor to provide a little bit of
> > background about himself.
> >
> > Congratulations and Welcome!
> >
> > -Andrew Palumbo
> > On Behalf of the Mahout PMC
> >
>

Re: Enabling compilation for java 1.8

[Stevo Slavić]

Consider moving enforcement to release profile so that during release we're
sure that 1.7 is used, while custom builds can be run with newer jdk.

On Tue, Sep 29, 2015 at 9:26 PM, Dmitriy Lyubimov  wrote:

> I see compilation with jdk 1.8 is prohibited, 1.7 only.
>
> I assume it is ok if I enable 1.8 compilation?
>

Re: [VOTE] Apache Mahout 0.10.2 Release Candidate

[Stevo Slavić]

+1 (binding) verified all signatures and hashes, all tests pass on build
from distribution source tarball

On Mon, Aug 3, 2015 at 2:22 AM, Andrew Musselman andrew.mussel...@gmail.com
 wrote:

 -1 unless this is operator error on my part.

 $ gpg --verify Downloads/apache-mahout-distribution-0.10.2-src.zip.asc
 gpg: no signed data
 gpg: can't hash datafile: file open error

 On Sun, Aug 2, 2015 at 11:58 AM, Suneel Marthi smar...@apache.org wrote:

  If u folks have not read the email from last friday that talks about both
  0.10.2 and 0.11.0 releases this week, I would suggest that you please do.
  The plan is to release both 0.10.2 and 0.11.0 this week.  Seems like we
  have some bandwidth in the PMC (atleast per the last 2 emails on this
  thread) to push thru another release today (I definitely don't have the
  time) .  If someone else wants to push thru 0.11.0,  please do so.
 
 
 
 
  On Sun, Aug 2, 2015 at 1:27 PM, Andrew Musselman 
  andrew.mussel...@gmail.com
   wrote:
 
   Is there any reason not to release 11 too?
  
   On Sunday, August 2, 2015, Pat Ferrel p...@occamsmachete.com wrote:
  
+1 (binding) — do we have to say binding?
   
Why do we continue on Spark 1.2 when all distros have updated to
 Spark
1.3.1 long ago, and Spark has released 1.4 with 1.5 in the works.
 This
  is
rather incomprehensible to me since we have the master 0.11.0,
 running
  on
1.4 ready to release.
   
Can we please, please also release 0.11.0?
   
On Aug 1, 2015, at 9:35 PM, Andrew Palumbo ap@outlook.com
javascript:; wrote:
   
Verified source tar and zip, all tests pass.
   
Ran through all options of the classification and clustering examples
  in
the binary tar.gz distribution in pseudo-cluster mode for MR and
 Spark
without incident.
   
Ran through one option each in the .zip  Classification and
 Clustering
examples in both pseudo-cluster and MAHOUT_LOCAL mode without
 incident.
   
Verified spark-document-classifier.mscala example from the
 spark-shell
  in
both .zip and .tar.gz binaries.
   
+1 (binding)
   
On 08/01/2015 12:44 AM, Suneel Marthi wrote:
 Verified {src} * {bin, tar} and all tests pass.

 +1 (binding)



 On Fri, Jul 31, 2015 at 11:56 PM, Suneel Marthi 
 smar...@apache.org
javascript:; wrote:

 This is a call for Votes for Mahout 0.10.2 Release candidate
  available
at

  
 https://repository.apache.org/content/repositories/orgapachemahout-1011

 Need atleast 3 PMC +1 votes for the RC to pass. Voting runs until
   Sunday
 Aug 2, 2015.


 Please verify the following:

 1. Sigs and Hashes of Release artifacts (Ted/Drew/Grant/Stevo)
 2. AWS testing of {src, bin} * {tar, zip}  (Andrew ?)
 3. Integration testing of {src,bin} * {tar,zip} (Suneel/AP/)
 4. Run thru Examples and scripts




   
   
   
  
 

Re: [VOTE] Apache Mahout 0.11.0 Release candidate

[Stevo Slavić]

Sorry for confusion, I thought it was for all artifacts. Suneel clarified,
it was just about not-merged change for distribution archives from 0.10.x
to 0.11.x/master branch. Will verify releases and cast my vote later today.

Kind regards,
Stevo Slavic.

On Mon, Aug 3, 2015 at 4:26 PM, Pat Ferrel p...@occamsmachete.com wrote:

 Is this Apache wide? It’s silly if not. We shouldn’t make this decision in
 a vacuum. Seems like the defacto standard is not to include “Apache in the
 artifact, I can’t think of anyone else who does.

 On Aug 3, 2015, at 3:29 AM, Suneel Marthi suneel.mar...@gmail.com wrote:

 We made that change on 0.10.x branch but was not merged in master, that's
 all that was there to be done.

 Otherwise I agree with what u r saying.

 Sent from my iPhone

  On Aug 3, 2015, at 4:48 AM, Stevo Slavić ssla...@gmail.com wrote:
 
  This keeps coming up often in recent releases, and I keep referring to
  https://issues.apache.org/jira/browse/MAHOUT-1680 where it was decided
 only
  to have distribution artifact/acrhive have apache prefix. Did something
  change since then?
 
  None of the Apache projects, java libraries, that I use, have apache
 prefix
  in their artifact name. It's though part of their groupId.
 
  If artifactId changes, people depending transitively and directly to
 Mahout
  modules might get classpath issues - same class, two different
  versions/APIs, and depending on class loader different one may be loaded
 in
  different context, or even fail to load.
 
  Kind regards,
  Stevo Slavic.
 
  On Mon, Aug 3, 2015 at 7:01 AM, Suneel Marthi smar...@apache.org
 wrote:
 
  Rolling back this release, there's a discrepancy in the artifact naming
  that needs to be addressed; will send an update when a new Release
  candidate is available.
 
  On Sun, Aug 2, 2015 at 7:42 PM, Suneel Marthi smar...@apache.org
 wrote:
 
  This is the vote for release 0.11.0 of Apache Mahout.
 
  The vote will be going for at least 72 hours and will be closed on
  Wednesday,
  August 5th, 2015.  Please download, test and vote with
 
  [ ] +1, accept RC as the official 0.11.0 release of Apache Mahout
  [ ] +0, I don't care either way,
  [ ] -1, do not accept RC as the official 0.11.0 release of Apache
 Mahout,
  because...
 
 
  Maven staging repo:
 
 
 https://repository.apache.org/content/repositories/orgapachemahout-1012
  
 
 https://repository.apache.org/content/repositories/orgapachemahout-1012/org/apache/mahout/mahout-distribution/0.11.0/
 
  
 https://repository.apache.org/content/repositories/orgapachebigtop-1001
 
 
  The git tag to be voted upon is release-0.11.0
 

Re: [VOTE] Apache Mahout 0.11.0 Release candidate

[Stevo Slavić]

This keeps coming up often in recent releases, and I keep referring to
https://issues.apache.org/jira/browse/MAHOUT-1680 where it was decided only
to have distribution artifact/acrhive have apache prefix. Did something
change since then?

None of the Apache projects, java libraries, that I use, have apache prefix
in their artifact name. It's though part of their groupId.

If artifactId changes, people depending transitively and directly to Mahout
modules might get classpath issues - same class, two different
versions/APIs, and depending on class loader different one may be loaded in
different context, or even fail to load.

Kind regards,
Stevo Slavic.

On Mon, Aug 3, 2015 at 7:01 AM, Suneel Marthi smar...@apache.org wrote:

 Rolling back this release, there's a discrepancy in the artifact naming
 that needs to be addressed; will send an update when a new Release
 candidate is available.

 On Sun, Aug 2, 2015 at 7:42 PM, Suneel Marthi smar...@apache.org wrote:

  This is the vote for release 0.11.0 of Apache Mahout.
 
  The vote will be going for at least 72 hours and will be closed on
  Wednesday,
  August 5th, 2015.  Please download, test and vote with
 
  [ ] +1, accept RC as the official 0.11.0 release of Apache Mahout
  [ ] +0, I don't care either way,
  [ ] -1, do not accept RC as the official 0.11.0 release of Apache Mahout,
  because...
 
 
  Maven staging repo:
 
  https://repository.apache.org/content/repositories/orgapachemahout-1012
  
 https://repository.apache.org/content/repositories/orgapachemahout-1012/org/apache/mahout/mahout-distribution/0.11.0/
 
  https://repository.apache.org/content/repositories/orgapachebigtop-1001
 
 
  The git tag to be voted upon is release-0.11.0
 
 

Re: [VOTE] Mahout 0.10.1 Release Candidate

[Stevo Slavić]

+1 (binding)

Verified hashes and signatures; distribution sources tarball and zip unpack
well, build passes from unpacked sources.

On Sun, May 31, 2015 at 8:34 PM, Andrew Musselman 
andrew.mussel...@gmail.com wrote:

 +1 (binding)

 Verified tests pass for src tarball and zip; I'm comfortable skipping EMR
 smoke testing for a point release given team opinion that it's not
 required.

 On Sun, May 31, 2015 at 9:43 AM, Andrew Palumbo ap@outlook.com
 wrote:

  +1 (binding)
 
  Ran (on Hadoop 2.4.1 + spark 1.2.1) all examples with all options in the
  |.tar.gz| binary archive in pseudo-cluster mode and one with
  MAHOUT_LOCAL=true with only the previously noted minor data issue, which
 I
  agree can wait for the next release.
 
  Ran a mix and match of the |.zip| binary archive examples with
  MAHOUT_LOCAL=true and in pseudo-cluster mode without issue.
 
  Tested the shell from both archives for qr and matrix display fixes.
 
 
 
  On 05/31/2015 12:09 PM, Pat Ferrel wrote:
 
  +1 (binding)
 
  Verified on Spark 1.3 psuedo-clustered HDFS 2.4
 
  There are some cleanup of example data issues that can wait for next
  release.
 
 
  On May 30, 2015, at 8:16 PM, Suneel Marthi smar...@apache.org wrote:
 
  Verified locally build and tests for {source} * {zip, tar}. No issues
  found.
 
  +1 (binding)
 
  On Sat, May 30, 2015 at 11:14 PM, Suneel Marthi smar...@apache.org
  wrote:
 
   Andrew Palumbo / Dmitriy:  Please also verify the various scenarios as
  described in M-1693
 
  On Sat, May 30, 2015 at 10:32 PM, Suneel Marthi smar...@apache.org
  wrote:
 
   Here's the new 0.10.1 Release Candidate
 
 
 
 
 https://repository.apache.org/content/repositories/orgapachemahout-1009/org/apache/mahout/apache-mahout-distribution/0.10.1/
 
  The Voting ends on Sunday, May 31 2015.
 
  Need a +1 from the PMC for each of the line items below for the
 release
  to pass.
 
  1. Ted/Grant:  Verify hashes and checksums - {binary,source} x
 {zip,tar}
  + pom
 
  2. AKM:  Verify examples on EMR  - {binary, source} * {zip, tar}
 
  3. Andrew Palumbo: Verify examples locally - {binary} * {zip, tar}
 
  4. Suneel: Verify build and tests - {source} * {zip, tar}
 
  5. Pat:  Verify examples locally - {source} * {zip, tar}
 
  The LICENSE and NOTICE files have not been updated this time and will
 be
  addressed in future releases.
 
 
 
  On Sat, May 30, 2015 at 8:32 PM, Suneel Marthi 
 suneel.mar...@gmail.com
  
  wrote:
 
   Please hold ur votes, will be refreshing staging with another build
 in
  the next hour
 
  On Sat, May 30, 2015 at 8:31 PM, Andrew Musselman 
  andrew.mussel...@gmail.com wrote:
 
   Likewise source zip and tarballs build and pass tests.
 
  On Sat, May 30, 2015 at 3:23 PM, Suneel Marthi smar...@apache.org
  wrote:
 
   Verified {source} * {zip, tar} and all tests pass.
 
  +1 (binding)
 
  On Sat, May 30, 2015 at 5:28 PM, Suneel Marthi smar...@apache.org
 
 
  wrote:
 
  This is a call for VOTE to pass Mahout 0.10.1 release candidate
 
  that's
 
  available at
 
 
 
 
 
 https://repository.apache.org/content/repositories/orgapachemahout-1008/org/apache/mahout/mahout-distribution/0.10.1/
 
  Need atleast 3 PMC +1 (binding) votes to cut the release
 
  Below are the tasks breakdown for the PMC and committers:
 
  Andy Palumbo  Pat Ferrel: verify the binary artifacts and run
 tests
 
  Suneel  AKM:  verify the src artifacts
 
  Ted/Grant/Drew: verify the hashes and Sigs
 
  The LICENSE.txt and NOTICE.txt still need to be updated and will
 
  not be
 
  addressed as part of 0.10.1 release.
 
 
 
 
 
 

Re: Welcome Anand Avati

[Stevo Slavić]

Congratulations and welcome Anand!
On Apr 22, 2015 8:30 PM, Andrew Palumbo ap@outlook.com wrote:

 Congratulations Anand, Welcome to the team!

 On 04/22/2015 02:18 PM, Gokhan Capan wrote:

 Welcome Anand!

 Sent from my iPhone

  On Apr 22, 2015, at 20:47, Dmitriy Lyubimov dlie...@gmail.com wrote:

 congrats and thank you!

 -d

 On Wed, Apr 22, 2015 at 10:33 AM, Andrew Musselman 
 andrew.mussel...@gmail.com wrote:

  Welcome to the team Anand; thanks for your contributions!

  On Wed, Apr 22, 2015 at 10:29 AM, Anand Avati av...@gluster.org
 wrote:

 Thank you Suneel, I am thrilled to join the team!

 I am a relative newbie to data mining and machine learning. I currently
 work at Red Hat, but have joined grad school (in machine learning)

 starting

 this fall.

 I look forward to continuing my contributions, and thank you once again

 for

 the opportunity.

 Anand

  On Wed, Apr 22, 2015, 08:08 Suneel Marthi smar...@apache.org wrote:

 In recognition of the contributions of Anand Avati to the Mahout

 project

 over the past year, the PMC is pleased to announce that he has accepted

 our

 invitation to join the Mahout project as a committer.

 As is customary, I will leave it to Anand to provide a little bit of
 background about himself.

 Congratulations and Welcome!

 -Suneel Marthi
 On Behalf of Mahout PMC

Re: [VOTE] Add Travis-CI for Mahout

[Stevo Slavić]

Before I cast my vote can somebody please explain which problem are we
trying to or expect from this to be solved?

Kind regards,
Stevo Slavic.
On Apr 17, 2015 9:22 AM, Ted Dunning ted.dunn...@gmail.com wrote:

 Totally simple if the project has a standard build/test structure.

 For t-digest it took about 4 lines of yaml checked into the root
 directory.  The documentation on travis is excellent and the process of
 setup is easy.


 On Fri, Apr 17, 2015 at 3:27 AM, Andrew Musselman 
 andrew.mussel...@gmail.com wrote:

  Worth trying out though I've never used Travis; what work effort is
  required, any idea?
 
  On Thursday, April 16, 2015, Suneel Marthi suneel.mar...@gmail.com
  wrote:
 
   Would this be an additional CI we would like to add to Mahout ?
  
   https://blogs.apache.org/infra/entry/apache_gains_additional_travis_ci
  
   I am up for it.
  
   +1
  
 

Re: Next version

[Stevo Slavić]

Not sure if I will be able to attend.

IMO, in major.minor.patch semantic versioning scheme (which I believe we're
applying and want to adhere to), there is no frequency dimension, there's
just scope dimension. There is nothing in versioning scheme preventing one
to release even major version multiple times during a single day.

Scope of patch release is expected to include bugfixes, documentation and
similar. It is also expected for a patch release to be backward compatible
- one can without touching sources upgrade only version number of a
dependency and have a previously buggy behavior now working as expected.
If we define a new 0.10.1 release with such scope, I'm fine with it.

So far scope for next release included backward incompatible changes, like
artifact name changes, and major dependency changes (like spark 1.1.1 to
spark 1.3.x) and more. That's why I proposed release with such scope to
have minor version part incremented, from 0.10 to 0.11.

I'm not sure but I doubt there's anything in Apache way of doing things,
that's preventing us from having both 0.10.1 and 0.11.0 releases planned
and worked on in parallel with dedicated branches e.g. master for next
major.minor/non-bug-fix release, and branches for bug fix supported
versions like 0.10 or 0.10.x. One can create a 0.10.x branch from 0.10.0
release tag. Changes there have to be regularly merged to master.

When it comes to frequency for bug fix / patch releases I wouldn't mind if
we released whenever a new bug fix (implementation or documentation) is
resolved and reviewed.

Kind regards,
Stevo Slavic.

On Tue, Apr 14, 2015 at 8:23 AM, Ted Dunning ted.dunn...@gmail.com wrote:

 A word of warning about making decisions off-list and without a permanent
 record on the mailing list.

 I will likely be available, but may not be.  I am happy with whatever the
 consensus is (with a tilt towards frequent releases), but would like to see
 most of the decision process on the list.


 On Tue, Apr 14, 2015 at 4:44 AM, Suneel Marthi suneel.mar...@gmail.com
 wrote:

  We should talk about this. Could the team slack tomorrow 1PM Eastern
 Time
  to talk this out and also finalize scope for the next one?
 
  On Mon, Apr 13, 2015 at 9:14 PM, Dmitriy Lyubimov dlie...@gmail.com
  wrote:
 
   i thought we wanted to do 0.10.1 with a quicker release cycle and
  bugfixes?
  
   On Sun, Apr 12, 2015 at 6:47 AM, Suneel Marthi 
 suneel.mar...@gmail.com
   wrote:
  
On Sun, Apr 12, 2015 at 8:56 AM, Stevo Slavić ssla...@gmail.com
  wrote:
   
 Hello team,

 Should next version be 0.10.1 or 0.11.0?

   
I am fine with just 0.11
   
   

 Thinking maybe 0.11.0 is more suitable, if it's going to contain
   artifact
 name changes like MAHOUT-1680 and MAHOUT-1681, and fundamental new
 features, so we keep minor releases for backward compatible bug fix
 releases only.

 Btw, it would be good (whoever has privileges) to have versions in
  JIRA
 project sorted out:
 - mark 0.10.0 as released
 - remove two empty 1.0-snapshot versions
 - move 1.0 to the top and clear its release date
 - move 0.10.1/0.11.0 under 1.0 and after 0.10.0

   
Stevo, u should have permissions now to fix all of the above.
   
   
 - maybe plan and set 0.10.1/0.11.0 expected release date (Suneel
 was
 mentioning it would be nice to integrate with Apache Flink by
 October
 timely for http://lanyrd.com/2015/flink-forward/ )

   
This would definitely be a good story to present at
http://lanyrd.com/2015/flink-forward/
   
The Flink team is ready to dedicate resources from their camp to work
   with
us.
   
   
 Kind regards,
 Stevo Slavic.

   
  
 

Re: Next version

[Stevo Slavić]

Btw, I volunteer to create a 0.10.x branch and any needed changes in build
scripts to make branch releasable. In JIRA I guess these days anyone
(including me) can create 0.10.1 version and define scope for it, assign
issues.

On Tue, Apr 14, 2015 at 9:14 AM, Suneel Marthi smar...@apache.org wrote:

 On Tue, Apr 14, 2015 at 3:11 AM, Ted Dunning ted.dunn...@gmail.com
 wrote:

  On Tue, Apr 14, 2015 at 8:49 AM, Stevo Slavić ssla...@gmail.com wrote:
 
   I'm not sure but I doubt there's anything in Apache way of doing
 things,
   that's preventing us from having both 0.10.1 and 0.11.0 releases
 planned
   and worked on in parallel with dedicated branches e.g. master for next
   major.minor/non-bug-fix release, and branches for bug fix supported
   versions like 0.10 or 0.10.x. One can create a 0.10.x branch from
 0.10.0
   release tag. Changes there have to be regularly merged to master.
  
 
  This is entirely up to the project from the Apache view point.
 
  (and speaking as a project member, it sounds like a good idea)
 

 And projects like Flink do this today, having multiple revision branches in
 tandem.

mahout-0.10.x branch

[Stevo Slavić]

Hello team,

mahout-0.10.x branch has been created for work on 0.10.1 release and any
future 0.10.x releases.

Project JIRA has 0.10.1 version defined so issues can be target to be fixed
for 0.10.1 release.

Somebody with privileges has to cover mahout-0.10.x branch with Jenkins
build jobs. Options vary, from updating existing jobs to handle all
branches (has downside that e.g. javadoc of Mahout-Quality would change
from 0.11 to 0.10.1, depending on which branch was last built), to manually
cloning jobs, to using dedicated Jenkins plugins with multi-branch
support/handling.

Kind regards,
Stevo Slavic.

Next version

[Stevo Slavić]

Hello team,

Should next version be 0.10.1 or 0.11.0?

Thinking maybe 0.11.0 is more suitable, if it's going to contain artifact
name changes like MAHOUT-1680 and MAHOUT-1681, and fundamental new
features, so we keep minor releases for backward compatible bug fix
releases only.

Btw, it would be good (whoever has privileges) to have versions in JIRA
project sorted out:
- mark 0.10.0 as released
- remove two empty 1.0-snapshot versions
- move 1.0 to the top and clear its release date
- move 0.10.1/0.11.0 under 1.0 and after 0.10.0
- maybe plan and set 0.10.1/0.11.0 expected release date (Suneel was
mentioning it would be nice to integrate with Apache Flink by October
timely for http://lanyrd.com/2015/flink-forward/ )

Kind regards,
Stevo Slavic.

MapR repo might need to be updated

[Stevo Slavić]

Hello Ted,

MapR Maven repository manager, seems to be Nexus, and it seems to be
version 2.11.1 or older with this bug still in it:
https://issues.sonatype.org/browse/NEXUS-7877

Mahout build uses MapR Maven repository, and for all artifacts/dependencies
resolved from it, build output is polluted with warnings like:


Downloading:
http://repository.mapr.com/maven/org/apache/apache/16/apache-16.pom
Mar 30, 2015 11:20:48 PM
org.apache.maven.wagon.providers.http.httpclient.client.protocol.ResponseProcessCookies
processCookies
WARNING: Cookie rejected [rememberMe=deleteMe, version:0, domain:
repository.mapr.com, path:/nexus, expiry:Mon Mar 30 23:20:48 CEST 2015]
Illegal path attribute /nexus. Path of origin:
/maven/org/apache/apache/16/apache-16.pom


Please consider having it updated.

Kind regards,
Stevo Slavic.

Anyone using eclipse?

[Stevo Slavić]

Hello team,

I'm curious, is anyone of you using eclipse IDE?
If not, then as part of MAHOUT-1278 I could remove a lot from our POMs.

Kind regards,
Stevo Slavic.

Re: [jira] [Commented] (MAHOUT-1650) Upgrade all 3rd party jars to the most recent versions and fix code to be Lucene 5.0 compatible

[Stevo Slavić]

I agree to keep them separate, didn't mean to replace one with another, was
just proposing to link them in JIRA, so it's easier to find out form JIRA
itself this information you gave me - that upgrade all isn't all truly,
that the lucene upgrade is separate ticket.

On Fri, Mar 27, 2015 at 3:27 PM, Suneel Marthi suneel.mar...@gmail.com
wrote:

 Not really, because Lucene upgrade involves some code rework; best to keep
 them separate IMO

 On Fri, Mar 27, 2015 at 10:25 AM, Stevo Slavić ssla...@gmail.com wrote:

  Yes, I'm aware of that other JIRA, thanks. Maybe we can link the two, as
  related issues in JIRA.
 
  On Fri, Mar 27, 2015 at 1:34 PM, Suneel Marthi (JIRA) j...@apache.org
  wrote:
 
  
   [
  
 
 https://issues.apache.org/jira/browse/MAHOUT-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14383766#comment-14383766
   ]
  
   Suneel Marthi commented on MAHOUT-1650:
   ---
  
   Stevo, FYI there is another Jira for Lucene 5 upgrade that Frank's
  working
   on, so this Jira would only have to deal with non-lucene upgrades.
  
Upgrade all 3rd party jars to the most recent versions and fix code
 to
   be Lucene 5.0 compatible
   
  
 
 ---
   
Key: MAHOUT-1650
URL:
 https://issues.apache.org/jira/browse/MAHOUT-1650
Project: Mahout
 Issue Type: Improvement
 Components: CLI
   Affects Versions: 0.9
   Reporter: Suneel Marthi
   Assignee: Stevo Slavic
Fix For: 0.10.0
   
   
The title pretty much is self-descriptive, otherwise modify the code
   using Lucene to account for the recent changes in Lucene
  
  
  
   --
   This message was sent by Atlassian JIRA
   (v6.3.4#6332)
  
 

Re: [jira] [Commented] (MAHOUT-1650) Upgrade all 3rd party jars to the most recent versions and fix code to be Lucene 5.0 compatible

[Stevo Slavić]

Yes, I'm aware of that other JIRA, thanks. Maybe we can link the two, as
related issues in JIRA.

On Fri, Mar 27, 2015 at 1:34 PM, Suneel Marthi (JIRA) j...@apache.org
wrote:


 [
 https://issues.apache.org/jira/browse/MAHOUT-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14383766#comment-14383766
 ]

 Suneel Marthi commented on MAHOUT-1650:
 ---

 Stevo, FYI there is another Jira for Lucene 5 upgrade that Frank's working
 on, so this Jira would only have to deal with non-lucene upgrades.

  Upgrade all 3rd party jars to the most recent versions and fix code to
 be Lucene 5.0 compatible
 
 ---
 
  Key: MAHOUT-1650
  URL: https://issues.apache.org/jira/browse/MAHOUT-1650
  Project: Mahout
   Issue Type: Improvement
   Components: CLI
 Affects Versions: 0.9
 Reporter: Suneel Marthi
 Assignee: Stevo Slavic
  Fix For: 0.10.0
 
 
  The title pretty much is self-descriptive, otherwise modify the code
 using Lucene to account for the recent changes in Lucene



 --
 This message was sent by Atlassian JIRA
 (v6.3.4#6332)

Re: build error

[Stevo Slavić]

Question is what is minimal Java that we should require Mahout users to
use. It was raised to 1.7 via MAHOUT-1652
https://issues.apache.org/jira/browse/MAHOUT-1652. It enables us to use
Java 1.7 APIs, finally. E.g. after level was raised I was recently able to
eliminate some usage of Guava for closing Closable's with using
try-with-resources Java 7 construct. We should minimize dependencies, there
are IMO too many. Depending more and more on standard libraries of Java and
Scala helps in that direction. Hopefully we do not wait much longer before
the level is raised even further to 1.8, so we have even less 3rd party
dependencies.

On Fri, Mar 27, 2015 at 5:31 PM, Pat Ferrel p...@occamsmachete.com wrote:

 It should, Hadoop supports it long term and lots of people stuck there
 with projects that haven’t been upgraded (Mahout comes to mind).

 On Mar 27, 2015, at 9:26 AM, Stevo Slavić ssla...@gmail.com wrote:

 Have to check but I doubt that build supports hadoop 1.x any more.

 On Fri, Mar 27, 2015 at 5:15 PM, Suneel Marthi suneel.mar...@gmail.com
 wrote:

  This is the Java version, gotta use Java 7
 
  On Fri, Mar 27, 2015 at 12:08 PM, Pat Ferrel p...@occamsmachete.com
  wrote:
 
  Latest source for Spark 1.1.0 and Hadoop 1.2.1
 
  Build complains about the move to
  maven.compiler.target1.7/maven.compiler.target I think this was
 upped
  from 1.6 but not sure if that’s what the error is about.
 
  I’m on Java 6 no this machine if that matters.
 
  Actual error:
 
  [INFO] Mahout Build Tools  SUCCESS
  [3.512s]
  [INFO] Apache Mahout . SUCCESS
  [0.603s]
  [INFO] Mahout Math ... FAILURE
  [6.453s]
  [INFO] Mahout MapReduce Legacy ... SKIPPED
  [INFO] Mahout Integration  SKIPPED
  [INFO] Mahout Examples ... SKIPPED
  [INFO] Mahout Release Package  SKIPPED
  [INFO] Mahout Math Scala bindings  SKIPPED
  [INFO] Mahout Spark bindings . SKIPPED
  [INFO] Mahout Spark bindings shell ... SKIPPED
  [INFO] Mahout H2O backend  SKIPPED
  [INFO]
  
  [INFO] BUILD FAILURE
  [INFO]
  
  [INFO] Total time: 11.609s
  [INFO] Finished at: Fri Mar 27 08:55:35 PDT 2015
  [INFO] Final Memory: 24M/310M
  [INFO]
  
  [ERROR] Failed to execute goal
  org.apache.maven.plugins:maven-compiler-plugin:3.2:compile
  (default-compile) on project mahout-math: Fatal error compiling: invalid
  target release: 1.7 - [Help 1]
  [ERROR]
  [ERROR] To see the full stack trace of the errors, re-run Maven with the
  -e switch.
  [ERROR] Re-run Maven using the -X switch to enable full debug logging.
  [ERROR]
 
 
 

Re: build error

[Stevo Slavić]

Have to check but I doubt that build supports hadoop 1.x any more.

On Fri, Mar 27, 2015 at 5:15 PM, Suneel Marthi suneel.mar...@gmail.com
wrote:

 This is the Java version, gotta use Java 7

 On Fri, Mar 27, 2015 at 12:08 PM, Pat Ferrel p...@occamsmachete.com
 wrote:

  Latest source for Spark 1.1.0 and Hadoop 1.2.1
 
  Build complains about the move to
  maven.compiler.target1.7/maven.compiler.target I think this was upped
  from 1.6 but not sure if that’s what the error is about.
 
  I’m on Java 6 no this machine if that matters.
 
  Actual error:
 
  [INFO] Mahout Build Tools  SUCCESS
 [3.512s]
  [INFO] Apache Mahout . SUCCESS
 [0.603s]
  [INFO] Mahout Math ... FAILURE
 [6.453s]
  [INFO] Mahout MapReduce Legacy ... SKIPPED
  [INFO] Mahout Integration  SKIPPED
  [INFO] Mahout Examples ... SKIPPED
  [INFO] Mahout Release Package  SKIPPED
  [INFO] Mahout Math Scala bindings  SKIPPED
  [INFO] Mahout Spark bindings . SKIPPED
  [INFO] Mahout Spark bindings shell ... SKIPPED
  [INFO] Mahout H2O backend  SKIPPED
  [INFO]
  
  [INFO] BUILD FAILURE
  [INFO]
  
  [INFO] Total time: 11.609s
  [INFO] Finished at: Fri Mar 27 08:55:35 PDT 2015
  [INFO] Final Memory: 24M/310M
  [INFO]
  
  [ERROR] Failed to execute goal
  org.apache.maven.plugins:maven-compiler-plugin:3.2:compile
  (default-compile) on project mahout-math: Fatal error compiling: invalid
  target release: 1.7 - [Help 1]
  [ERROR]
  [ERROR] To see the full stack trace of the errors, re-run Maven with the
  -e switch.
  [ERROR] Re-run Maven using the -X switch to enable full debug logging.
  [ERROR]
 
 

Re: Jenkins build is back to normal : Mahout-Quality #3015

[Stevo Slavić]

We're green again, yay! :)

At least one test is unstable, from time to time local build fails for:

TestDistributedRowMatrix.testTranspose:88 » IllegalState transposition
failed

Is it just my local env or does it happen for you too?

Kind regards,
Stevo Slavic.

On Thu, Mar 26, 2015 at 5:42 PM, Apache Jenkins Server 
jenk...@builds.apache.org wrote:

 See https://builds.apache.org/job/Mahout-Quality/3015/changes

Re: Jenkins build is back to normal : Mahout-Quality #3015

[Stevo Slavić]

Pleasure. Would be nice now to get fix for MAHOUT-1655 in. Waiting for more
reviews?

Since there were couple of pom changes in fixes for MAHOUT-1590, PR/commit
for MAHOUT-1655 needs to be rebased, sorry.

On Thu, Mar 26, 2015 at 6:41 PM, Andrew Musselman 
andrew.mussel...@gmail.com wrote:

 Yep still clean, thanks Stevo!

 On Thu, Mar 26, 2015 at 10:14 AM, Andrew Musselman 
 andrew.mussel...@gmail.com wrote:

  Been getting clean builds in the last hour, trying again.
 
  On Thu, Mar 26, 2015 at 10:01 AM, Stevo Slavić ssla...@gmail.com
 wrote:
 
  We're green again, yay! :)
 
  At least one test is unstable, from time to time local build fails for:
 
  TestDistributedRowMatrix.testTranspose:88 » IllegalState transposition
  failed
 
  Is it just my local env or does it happen for you too?
 
  Kind regards,
  Stevo Slavic.
 
  On Thu, Mar 26, 2015 at 5:42 PM, Apache Jenkins Server 
  jenk...@builds.apache.org wrote:
 
   See https://builds.apache.org/job/Mahout-Quality/3015/changes
  
  
 
 
 

Re: [jira] [Commented] (MAHOUT-1652) Java 7 update

[Stevo Slavić]

Which version of Java is the build running on?

Also, Maven version seems to be old, 3.0.4, would be nice to get that
updated too in build job definition.

Kind regards,
Stevo Slavic.
On Mar 25, 2015 8:44 AM, Hudson (JIRA) j...@apache.org wrote:


 [
 https://issues.apache.org/jira/browse/MAHOUT-1652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14379439#comment-14379439
 ]

 Hudson commented on MAHOUT-1652:
 

 FAILURE: Integrated in Mahout-Quality #3007 (See [
 https://builds.apache.org/job/Mahout-Quality/3007/])
 MAHOUT-1652: Java 7 update, upgrading maven-compiler-plugin to 3.2 to fix
 Jenkins failures with Java 7 (suneel.marthi: rev
 4d3a3863552e23c4aaafd82545222b0e6a3cd1fd)
 * pom.xml


  Java 7 update
  -
 
  Key: MAHOUT-1652
  URL: https://issues.apache.org/jira/browse/MAHOUT-1652
  Project: Mahout
   Issue Type: Dependency upgrade
 Affects Versions: 0.10.0
 Reporter: Andrew Musselman
 Assignee: Suneel Marthi
 Priority: Critical
  Fix For: 0.10.0
 
 
  Support Java 7



 --
 This message was sent by Atlassian JIRA
 (v6.3.4#6332)

Re: [jira] [Commented] (MAHOUT-1652) Java 7 update

[Stevo Slavić]

For both Maven and Java configurations of all our build jobs have to be
updated.

On Wed, Mar 25, 2015 at 2:29 PM, Suneel Marthi suneel.mar...@gmail.com
wrote:

 Jenkins been running Java 6 for a long while now. Is there something that
 needs to be done to point Jenkins to Java 7 ?

 Will upgrade Maven version too, there's a JIRA in place to upgrade all of
 the 3rd party libs to the most recent versiions.

 On Wed, Mar 25, 2015 at 4:19 AM, Stevo Slavić ssla...@gmail.com wrote:

  Which version of Java is the build running on?
 
  Also, Maven version seems to be old, 3.0.4, would be nice to get that
  updated too in build job definition.
 
  Kind regards,
  Stevo Slavic.
  On Mar 25, 2015 8:44 AM, Hudson (JIRA) j...@apache.org wrote:
 
  
   [
  
 
 https://issues.apache.org/jira/browse/MAHOUT-1652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14379439#comment-14379439
   ]
  
   Hudson commented on MAHOUT-1652:
   
  
   FAILURE: Integrated in Mahout-Quality #3007 (See [
   https://builds.apache.org/job/Mahout-Quality/3007/])
   MAHOUT-1652: Java 7 update, upgrading maven-compiler-plugin to 3.2 to
 fix
   Jenkins failures with Java 7 (suneel.marthi: rev
   4d3a3863552e23c4aaafd82545222b0e6a3cd1fd)
   * pom.xml
  
  
Java 7 update
-
   
Key: MAHOUT-1652
URL:
 https://issues.apache.org/jira/browse/MAHOUT-1652
Project: Mahout
 Issue Type: Dependency upgrade
   Affects Versions: 0.10.0
   Reporter: Andrew Musselman
   Assignee: Suneel Marthi
   Priority: Critical
Fix For: 0.10.0
   
   
Support Java 7
  
  
  
   --
   This message was sent by Atlassian JIRA
   (v6.3.4#6332)
  
 

Re: [jira] [Commented] (MAHOUT-1652) Java 7 update

[Stevo Slavić]

Which JDK version are bigtop guys targeting for their release?

On Wed, Mar 25, 2015 at 3:57 PM, Andrew Musselman 
andrew.mussel...@gmail.com wrote:

 Okay, just did that one too.

 On Wed, Mar 25, 2015 at 7:53 AM, Suneel Marthi suneel.mar...@gmail.com
 wrote:

  Need it done for Mahout-Quality first, since that's where all the jiras
  first go to.
 
  On Wed, Mar 25, 2015 at 10:49 AM, Andrew Musselman 
  andrew.mussel...@gmail.com wrote:
 
   For both mahout-nightly and mahout-collections-trunk.
  
   On Wed, Mar 25, 2015 at 7:47 AM, Andrew Musselman 
   andrew.mussel...@gmail.com wrote:
  
Just changed the JDK this project uses from JDK 1.6 (latest) to
 JDK
   1.7
(latest).
   
On Wed, Mar 25, 2015 at 7:45 AM, Andrew Musselman 
andrew.mussel...@gmail.com wrote:
   
Got it, I'm in.
   
On Wed, Mar 25, 2015 at 7:06 AM, Andrew Musselman 
andrew.mussel...@gmail.com wrote:
   
Trying to discover my login credentials now.
   
On Wed, Mar 25, 2015 at 7:05 AM, Suneel Marthi 
   suneel.mar...@gmail.com
wrote:
   
https://builds.apache.org/job/Mahout-Quality/3007/
   
Start with the above, whatever it takes, it needs to be done for
  each
   of
the Mahout jobs.
   
You may want to add Stevo and me to the list of authorized users.
   Stevo
knows this best and can fix it real quick if granted admin access.
   
On Wed, Mar 25, 2015 at 10:01 AM, Andrew Musselman 
andrew.mussel...@gmail.com wrote:
   
 According to this mail from Grant in May of last year, Frank,
Sebastian,
 and I all do now; do you know the URL to the admin page?


 Grant Ingersoll gsing...@apache.org
 5/4/14
 to Frank, Andrew, private
 I added Frank and Andrew to the Jenkins group (as well as
  Sebastian)

 On Wed, Mar 25, 2015 at 6:54 AM, Suneel Marthi 
suneel.mar...@gmail.com
 wrote:

  Hmmm, so unless someone mucks with Jenkins now we're gonna
 see a
spate of
  failed jobs !!
 
  Who has Jenkins Admin permissions in this group?? Ted, Grant
 ???
 
  IIRC we have had to do something like this in the run up for
 0.8
release
  back in 2013, not sure who did it then??
 
  On Wed, Mar 25, 2015 at 9:48 AM, Stevo Slavić 
  ssla...@gmail.com
wrote:
 
   Build jobs in Jenkins; you already changed needed part in
 pom
file.
  
   On Wed, Mar 25, 2015 at 2:41 PM, Suneel Marthi 
 suneel.mar...@gmail.com
   wrote:
  
Updated on Jenkins  or would that be in our Project
 poms
   ??
   
On Wed, Mar 25, 2015 at 9:39 AM, Stevo Slavić 
ssla...@gmail.com
  wrote:
   
 For both Maven and Java configurations of all our build
  jobs
have
 to
  be
 updated.

 On Wed, Mar 25, 2015 at 2:29 PM, Suneel Marthi 
   suneel.mar...@gmail.com
 wrote:

  Jenkins been running Java 6 for a long while now. Is
  there
  something
that
  needs to be done to point Jenkins to Java 7 ?
 
  Will upgrade Maven version too, there's a JIRA in
 place
  to
 upgrade
   all
of
  the 3rd party libs to the most recent versiions.
 
  On Wed, Mar 25, 2015 at 4:19 AM, Stevo Slavić 
ssla...@gmail.com
 
wrote:
 
   Which version of Java is the build running on?
  
   Also, Maven version seems to be old, 3.0.4, would be
   nice
to
 get
   that
   updated too in build job definition.
  
   Kind regards,
   Stevo Slavic.
   On Mar 25, 2015 8:44 AM, Hudson (JIRA) 
   j...@apache.org

  wrote:
  
   
[
   
  
 

   
  
 

   
  
 
 https://issues.apache.org/jira/browse/MAHOUT-1652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14379439#comment-14379439
]
   
Hudson commented on MAHOUT-1652:

   
FAILURE: Integrated in Mahout-Quality #3007 (See [
   
 https://builds.apache.org/job/Mahout-Quality/3007/
  ])
MAHOUT-1652: Java 7 update, upgrading
maven-compiler-plugin
 to
   3.2
to
  fix
Jenkins failures with Java 7 (suneel.marthi: rev
4d3a3863552e23c4aaafd82545222b0e6a3cd1fd)
* pom.xml
   
   
 Java 7 update
 -

 Key: MAHOUT-1652
 URL:
  https://issues.apache.org/jira/browse/MAHOUT-1652
 Project: Mahout
  Issue Type: Dependency upgrade
Affects Versions: 0.10.0
Reporter: Andrew Musselman
Assignee

Re: [jira] [Commented] (MAHOUT-1652) Java 7 update

[Stevo Slavić]

Seems 1.7 so we should be compatible with upgrade.
https://github.com/apache/bigtop/blob/master/build.gradle#L18

On Wed, Mar 25, 2015 at 4:10 PM, Suneel Marthi suneel.mar...@gmail.com
wrote:

 Question to ask the Big Top guys. http://bigtop.apache.org/ still has it
 as
 Java 6, but not sure if that's right?


 On Wed, Mar 25, 2015 at 10:58 AM, Stevo Slavić ssla...@gmail.com wrote:

  Which JDK version are bigtop guys targeting for their release?
 
  On Wed, Mar 25, 2015 at 3:57 PM, Andrew Musselman 
  andrew.mussel...@gmail.com wrote:
 
   Okay, just did that one too.
  
   On Wed, Mar 25, 2015 at 7:53 AM, Suneel Marthi 
 suneel.mar...@gmail.com
   wrote:
  
Need it done for Mahout-Quality first, since that's where all the
 jiras
first go to.
   
On Wed, Mar 25, 2015 at 10:49 AM, Andrew Musselman 
andrew.mussel...@gmail.com wrote:
   
 For both mahout-nightly and mahout-collections-trunk.

 On Wed, Mar 25, 2015 at 7:47 AM, Andrew Musselman 
 andrew.mussel...@gmail.com wrote:

  Just changed the JDK this project uses from JDK 1.6 (latest) to
   JDK
 1.7
  (latest).
 
  On Wed, Mar 25, 2015 at 7:45 AM, Andrew Musselman 
  andrew.mussel...@gmail.com wrote:
 
  Got it, I'm in.
 
  On Wed, Mar 25, 2015 at 7:06 AM, Andrew Musselman 
  andrew.mussel...@gmail.com wrote:
 
  Trying to discover my login credentials now.
 
  On Wed, Mar 25, 2015 at 7:05 AM, Suneel Marthi 
 suneel.mar...@gmail.com
  wrote:
 
  https://builds.apache.org/job/Mahout-Quality/3007/
 
  Start with the above, whatever it takes, it needs to be done
 for
each
 of
  the Mahout jobs.
 
  You may want to add Stevo and me to the list of authorized
  users.
 Stevo
  knows this best and can fix it real quick if granted admin
  access.
 
  On Wed, Mar 25, 2015 at 10:01 AM, Andrew Musselman 
  andrew.mussel...@gmail.com wrote:
 
   According to this mail from Grant in May of last year,
 Frank,
  Sebastian,
   and I all do now; do you know the URL to the admin page?
  
  
   Grant Ingersoll gsing...@apache.org
   5/4/14
   to Frank, Andrew, private
   I added Frank and Andrew to the Jenkins group (as well as
Sebastian)
  
   On Wed, Mar 25, 2015 at 6:54 AM, Suneel Marthi 
  suneel.mar...@gmail.com
   wrote:
  
Hmmm, so unless someone mucks with Jenkins now we're gonna
   see a
  spate of
failed jobs !!
   
Who has Jenkins Admin permissions in this group?? Ted,
 Grant
   ???
   
IIRC we have had to do something like this in the run up
 for
   0.8
  release
back in 2013, not sure who did it then??
   
On Wed, Mar 25, 2015 at 9:48 AM, Stevo Slavić 
ssla...@gmail.com
  wrote:
   
 Build jobs in Jenkins; you already changed needed part
 in
   pom
  file.

 On Wed, Mar 25, 2015 at 2:41 PM, Suneel Marthi 
   suneel.mar...@gmail.com
 wrote:

  Updated on Jenkins  or would that be in our
 Project
   poms
 ??
 
  On Wed, Mar 25, 2015 at 9:39 AM, Stevo Slavić 
  ssla...@gmail.com
wrote:
 
   For both Maven and Java configurations of all our
  build
jobs
  have
   to
be
   updated.
  
   On Wed, Mar 25, 2015 at 2:29 PM, Suneel Marthi 
 suneel.mar...@gmail.com
   wrote:
  
Jenkins been running Java 6 for a long while now.
 Is
there
something
  that
needs to be done to point Jenkins to Java 7 ?
   
Will upgrade Maven version too, there's a JIRA in
   place
to
   upgrade
 all
  of
the 3rd party libs to the most recent versiions.
   
On Wed, Mar 25, 2015 at 4:19 AM, Stevo Slavić 
  ssla...@gmail.com
   
  wrote:
   
 Which version of Java is the build running on?

 Also, Maven version seems to be old, 3.0.4,
 would
  be
 nice
  to
   get
 that
 updated too in build job definition.

 Kind regards,
 Stevo Slavic.
 On Mar 25, 2015 8:44 AM, Hudson (JIRA) 
 j...@apache.org
  
wrote:

 
  [
 

   
  
 

   
  
 

   
  
 
 https://issues.apache.org/jira/browse/MAHOUT-1652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14379439#comment-14379439
  ]
 
  Hudson commented on MAHOUT-1652:
  
 
  FAILURE: Integrated in Mahout-Quality #3007
  (See [
 
   https

Re: Build failed in Jenkins: Mahout-Quality #3009

[Stevo Slavić]

Will take few hours before I'm in commit mode, so if you cannot wait that
long, do go ahead and apply patch.

On Wed, Mar 25, 2015 at 4:16 PM, Suneel Marthi suneel.mar...@gmail.com
wrote:

 please go ahead and commit that patch, I think I have hadoop version at
 2.6.0 which seems to have caused this guava conflicts.

 On Wed, Mar 25, 2015 at 11:13 AM, Stevo Slavić ssla...@gmail.com wrote:

  Fixing (applying patch from)
  https://issues.apache.org/jira/browse/MAHOUT-1590 should fix this one.
 
  On Wed, Mar 25, 2015 at 4:07 PM, Apache Jenkins Server 
  jenk...@builds.apache.org wrote:
 
   See https://builds.apache.org/job/Mahout-Quality/3009/
  
   --
   [...truncated 5341 lines...]
   at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:70)
   at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:84)
   at
  
 
 org.apache.mahout.cf.taste.hadoop.als.ParallelALSFactorizationJobTest.recommenderJobWithIDMapping(ParallelALSFactorizationJobTest.java:345)
  
   Running org.apache.mahout.classifier.df.tools.VisualizerTest
   Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.72
 sec
  -
   in org.apache.mahout.classifier.df.tools.VisualizerTest
   Running org.apache.mahout.classifier.df.split.RegressionSplitTest
   Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.611
 sec
   - in org.apache.mahout.classifier.df.split.RegressionSplitTest
   Running org.apache.mahout.classifier.df.split.DefaultIgSplitTest
   Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.646
 sec
   - in org.apache.mahout.classifier.df.split.DefaultIgSplitTest
   Running org.apache.mahout.classifier.df.node.NodeTest
   Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.279
 sec
   - in org.apache.mahout.classifier.df.node.NodeTest
   Running
 org.apache.mahout.classifier.df.mapreduce.partial.Step1MapperTest
   Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.878
 sec
   - in org.apache.mahout.classifier.df.mapreduce.partial.Step1MapperTest
   Running
   org.apache.mahout.classifier.df.mapreduce.partial.PartialBuilderTest
   Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.556
 sec
   - in
 org.apache.mahout.classifier.df.mapreduce.partial.PartialBuilderTest
   Running org.apache.mahout.classifier.df.mapreduce.partial.TreeIDTest
   Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.966
 sec
   - in org.apache.mahout.classifier.df.mapreduce.partial.TreeIDTest
   Running
  org.apache.mahout.classifier.df.mapreduce.inmem.InMemInputSplitTest
   Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.288
 sec
   - in
 org.apache.mahout.classifier.df.mapreduce.inmem.InMemInputSplitTest
   Running
   org.apache.mahout.classifier.df.mapreduce.inmem.InMemInputFormatTest
   Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.775
 sec
   - in
 org.apache.mahout.classifier.df.mapreduce.inmem.InMemInputFormatTest
   Running org.apache.mahout.classifier.df.DecisionForestTest
   Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.679
 sec
   - in org.apache.mahout.classifier.df.DecisionForestTest
   Running org.apache.mahout.classifier.df.data.DataConverterTest
   Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.788
 sec
   - in org.apache.mahout.classifier.df.data.DataConverterTest
   Running org.apache.mahout.classifier.df.data.DatasetTest
   Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.708
 sec
   - in org.apache.mahout.classifier.df.data.DatasetTest
   Running org.apache.mahout.classifier.df.data.DataTest
   Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.257
  sec
   - in org.apache.mahout.classifier.df.data.DataTest
   Running org.apache.mahout.classifier.df.data.DataLoaderTest
   Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.432
 sec
   - in org.apache.mahout.classifier.df.data.DataLoaderTest
   Running org.apache.mahout.classifier.df.data.DescriptorUtilsTest
   Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.358
 sec
   - in org.apache.mahout.classifier.df.data.DescriptorUtilsTest
   Running org.apache.mahout.classifier.df.builder.DecisionTreeBuilderTest
   Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.344
 sec
   - in org.apache.mahout.classifier.df.builder.DecisionTreeBuilderTest
   Running org.apache.mahout.classifier.df.builder.DefaultTreeBuilderTest
   Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.327
 sec
   - in org.apache.mahout.classifier.df.builder.DefaultTreeBuilderTest
   Running org.apache.mahout.classifier.df.builder.InfiniteRecursionTest
   Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.656
 sec
   - in org.apache.mahout.classifier.df.builder.InfiniteRecursionTest
   Running org.apache.mahout.classifier.ConfusionMatrixTest
   Tests run: 3, Failures: 0, Errors: 0

Re: Build failed in Jenkins: Mahout-Quality #3009

[Stevo Slavić]

Fixing (applying patch from)
https://issues.apache.org/jira/browse/MAHOUT-1590 should fix this one.

On Wed, Mar 25, 2015 at 4:07 PM, Apache Jenkins Server 
jenk...@builds.apache.org wrote:

 See https://builds.apache.org/job/Mahout-Quality/3009/

 --
 [...truncated 5341 lines...]
 at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:70)
 at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:84)
 at
 org.apache.mahout.cf.taste.hadoop.als.ParallelALSFactorizationJobTest.recommenderJobWithIDMapping(ParallelALSFactorizationJobTest.java:345)

 Running org.apache.mahout.classifier.df.tools.VisualizerTest
 Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.72 sec -
 in org.apache.mahout.classifier.df.tools.VisualizerTest
 Running org.apache.mahout.classifier.df.split.RegressionSplitTest
 Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.611 sec
 - in org.apache.mahout.classifier.df.split.RegressionSplitTest
 Running org.apache.mahout.classifier.df.split.DefaultIgSplitTest
 Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.646 sec
 - in org.apache.mahout.classifier.df.split.DefaultIgSplitTest
 Running org.apache.mahout.classifier.df.node.NodeTest
 Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.279 sec
 - in org.apache.mahout.classifier.df.node.NodeTest
 Running org.apache.mahout.classifier.df.mapreduce.partial.Step1MapperTest
 Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.878 sec
 - in org.apache.mahout.classifier.df.mapreduce.partial.Step1MapperTest
 Running
 org.apache.mahout.classifier.df.mapreduce.partial.PartialBuilderTest
 Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.556 sec
 - in org.apache.mahout.classifier.df.mapreduce.partial.PartialBuilderTest
 Running org.apache.mahout.classifier.df.mapreduce.partial.TreeIDTest
 Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.966 sec
 - in org.apache.mahout.classifier.df.mapreduce.partial.TreeIDTest
 Running org.apache.mahout.classifier.df.mapreduce.inmem.InMemInputSplitTest
 Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.288 sec
 - in org.apache.mahout.classifier.df.mapreduce.inmem.InMemInputSplitTest
 Running
 org.apache.mahout.classifier.df.mapreduce.inmem.InMemInputFormatTest
 Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.775 sec
 - in org.apache.mahout.classifier.df.mapreduce.inmem.InMemInputFormatTest
 Running org.apache.mahout.classifier.df.DecisionForestTest
 Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.679 sec
 - in org.apache.mahout.classifier.df.DecisionForestTest
 Running org.apache.mahout.classifier.df.data.DataConverterTest
 Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.788 sec
 - in org.apache.mahout.classifier.df.data.DataConverterTest
 Running org.apache.mahout.classifier.df.data.DatasetTest
 Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.708 sec
 - in org.apache.mahout.classifier.df.data.DatasetTest
 Running org.apache.mahout.classifier.df.data.DataTest
 Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.257 sec
 - in org.apache.mahout.classifier.df.data.DataTest
 Running org.apache.mahout.classifier.df.data.DataLoaderTest
 Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.432 sec
 - in org.apache.mahout.classifier.df.data.DataLoaderTest
 Running org.apache.mahout.classifier.df.data.DescriptorUtilsTest
 Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.358 sec
 - in org.apache.mahout.classifier.df.data.DescriptorUtilsTest
 Running org.apache.mahout.classifier.df.builder.DecisionTreeBuilderTest
 Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.344 sec
 - in org.apache.mahout.classifier.df.builder.DecisionTreeBuilderTest
 Running org.apache.mahout.classifier.df.builder.DefaultTreeBuilderTest
 Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.327 sec
 - in org.apache.mahout.classifier.df.builder.DefaultTreeBuilderTest
 Running org.apache.mahout.classifier.df.builder.InfiniteRecursionTest
 Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.656 sec
 - in org.apache.mahout.classifier.df.builder.InfiniteRecursionTest
 Running org.apache.mahout.classifier.ConfusionMatrixTest
 Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.339 sec
 - in org.apache.mahout.classifier.ConfusionMatrixTest
 Running org.apache.mahout.classifier.mlp.TestMultilayerPerceptron
 Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 39.484 sec
 - in
 org.apache.mahout.cf.taste.impl.recommender.svd.ParallelSGDFactorizerTest
 Running org.apache.mahout.classifier.mlp.TestNeuralNetwork
 Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.939 sec
 - in org.apache.mahout.classifier.mlp.TestMultilayerPerceptron
 Running 

Re: 0.10 release Hangout

[Stevo Slavić]

We should consider migrating entire project from Maven to SBT, since
project includes several Scala modules, for them to be usable to community
IMO it's pretty much expected if not a must to publish them across current
Scala binary versions, 2.10 and 2.11, and Maven is simply not up to that
task.

Kind regards,
Stevo Slavic.

On Tue, Mar 24, 2015 at 4:36 PM, Pat Ferrel p...@occamsmachete.com wrote:

 Andrew are you keeper of the agenda?

 I only have the first hour so my $0.02 worth.
 1) Agree with Suneel that one top goal should be a Hadoop 2, Java 7,
 upgraded libs version of mrlegacy because at this point no Mahout release
 runs on the big distros.
 2) Refactor of mrlegacy to remove it as a dependency of the scala
 environment
 3) can we hand out docs to volunteers? This may mostly be done but I think
 Andy would know better. I’ll take legacy and scala recommender stuff and an
 example of writing an app that uses Mahout as a lib.
 4) get a volunteer to do whatever is required to perform the release
 (pending the vote) and any necessary build changes to get there (Suneel?)

 On Mar 23, 2015, at 2:21 PM, Andrew Musselman andrew.mussel...@gmail.com
 wrote:

 Moving an hour later so more people can attend; so 10 a.m. to noon Pacific.

 On Mon, Mar 23, 2015 at 1:19 PM, Andrew Musselman 
 andrew.mussel...@gmail.com wrote:

  We're splitting the difference so people in Europe can attend..
 
  On Mon, Mar 23, 2015 at 1:15 PM, Saikat Kanjilal sxk1...@hotmail.com
  wrote:
 
  Me2 and cant attend during those hours, thought I'd ask is it completely
  out of the question to do it during evenings pacific time?
 
  Date: Mon, 23 Mar 2015 16:01:50 -0400
  From: squ...@gatech.edu
  To: dev@mahout.apache.org
  Subject: Re: 0.10 release Hangout
 
  Will be teaching until 9:30 PT, at which point I have another meeting
  until 11. Would love to get a summary of the meeting; also happy to
 help
  with some of the tasks.
 
  Shannon
 
  On 3/23/15 3:56 PM, Andrew Musselman wrote:
  We'll be getting on a Google Hangout tomorrow, Tuesday, from 9-11 a.m.
  Pacific, to work through open questions for what should be in the
  release,
  go through Jira, and do some delegation of tasks.
 
  Here's the Hangout URL
 
 
 https://plus.google.com/hangouts/_/calendar/YW5kcmV3Lm11c3NlbG1hbkBnbWFpbC5jb20.glvu1gfv3kvj5241n9bsg3clrc
 
  See you then!
 
 
 
 
 
 

Re: [jira] [Created] (MAHOUT-1654) Migrate from Maven to SBT

[Stevo Slavić]

Hello Dmitriy,

Jenkins should be a no-brainer, nothing fundamentally different from Maven
in that regard. Will add subtasks to JIRA, including task for updating of
Jenkins build definitions. During WIP they can be new/separate build
job(s). I'm not scared of build engineering, but don't have appropriate
access rights on https://builds.apache.org/ to make work easier, e.g.
cannot create new job or edit existing Mahout jobs - that would make work
easier. Maybe just infra can create separate job(s) for me to work on this
migration.

One concern (time/effort wise) I have is the custom maven plugin we have
for collections code generation, equivalent has to be made available for
sbt, or some other solution found. Never liked that the code generation was
running on every build, over and over again; maybe that can be improved.

Kind regards
Stevo Slavic.



On Tue, Mar 24, 2015 at 7:22 PM, Dmitriy Lyubimov dlie...@gmail.com wrote:

 ok... but this will require also reworking jenkins and CI builds... and
 build engineering always scared me :)

 On Tue, Mar 24, 2015 at 10:54 AM, Stevo Slavic (JIRA) j...@apache.org
 wrote:

  Stevo Slavic created MAHOUT-1654:
  
 
   Summary: Migrate from Maven to SBT
   Key: MAHOUT-1654
   URL: https://issues.apache.org/jira/browse/MAHOUT-1654
   Project: Mahout
Issue Type: Improvement
Components: build
  Reporter: Stevo Slavic
  Assignee: Stevo Slavic
 
 
  Mahout modules which are Scala libraries like mahout-math-scala,
  mahout-spark/mahout-spark-shell, should be published across Scala binary
  versions to be usable to wider audience. At the moment this is not
 possible
  with Maven. We need to switch to another build tool which supports this,
  and SBT is most natural choice. Besides allowing us to publish Mahout
 Scala
  libraries across Scala binary versions, it is expected that this
 migration
  will help us mitigate/resolve other issues (to name a few, issue of
  publishing javadoc/scaladoc documentation, and long standing issue of
  migration to modern CLI library with sources).
 
  As acceptance criteria of migration success it should be defined that
 both
  project committers and users see only improvements/benefits, everything
  else that was possible and available with existing Maven build should be
  possible with SBT.
 
 
 
  --
  This message was sent by Atlassian JIRA
  (v6.3.4#6332)
 

Re: [jira] [Commented] (MAHOUT-1655) Refactor module dependencies

[Stevo Slavić]

If I understand correctly, mrlegacy should remain, just hdfs/non-mr stuff
extracted into separate module, for reuse in math-scala and mahout-spark
module, so they do not depend on mrlegacy?

Maybe we should rename mrlegacy to mahout-mr or mahout-mapred or
mahout-mapreduce. Legacy, if kept in master branch doesn't mean anything.

Kind regards,
Stevo Slavic.

On Tue, Mar 24, 2015 at 9:30 PM, Pat Ferrel (JIRA) j...@apache.org wrote:


 [
 https://issues.apache.org/jira/browse/MAHOUT-1655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14378530#comment-14378530
 ]

 Pat Ferrel commented on MAHOUT-1655:
 

 We can work together if you want to start a MAHOUT-1655 branch on your
 personal github repo.

  Refactor module dependencies
  
 
  Key: MAHOUT-1655
  URL: https://issues.apache.org/jira/browse/MAHOUT-1655
  Project: Mahout
   Issue Type: Improvement
   Components: mrlegacy
 Reporter: Pat Ferrel
 Assignee: Andrew Musselman
 Priority: Critical
  Fix For: 0.10.0
 
 
  Make a new module, call it mahout-hadoop. Move anything there that is
 currently in mrlegacy but used in math-scala or spark. Remove dependencies
 on mrlegacy altogether if possible by using other core classes.
  The goal is to have math-scala and spark module depend on math, and a
 small module called mahout-hadoop (much smaller than mrlegacy).



 --
 This message was sent by Atlassian JIRA
 (v6.3.4#6332)

Re: Broken build?

[Stevo Slavić]

http://repo1.maven.org/maven2/ai/h2o/h2o-core/0.1.5/h2o-core-0.1.5.pom is
broken, junit dependency version is invalid (4.+ does not work for Maven,
although it works in Ivy based build tools like Gradle and sbt).

Solution should be simple: just bump h20 dependency version
https://github.com/apache/mahout/blob/master/pom.xml#L115
There are multiple newer h20 releases available:
http://repo1.maven.org/maven2/ai/h2o/h2o-core/

Kind regards,
Stevo Slavic

On Tue, Dec 16, 2014 at 11:53 PM, Andrew Musselman 
andrew.mussel...@gmail.com wrote:

 If there are any h2o folks interested in taking a look with me I can spend
 some time on it; it's technically a bug but yeah it might be from having a
 really weird setup.

  On Dec 16, 2014, at 2:24 PM, Dmitriy Lyubimov dlie...@gmail.com wrote:
 
  Well now that at least anyone else is able to reproduce this, maybe.
 
  But then it may turn out some more or less common incompatibility.
 problem
  is, it looks like it is extremely hard to reproduce. Who knows, maybe it
 is
  because i simply have multiple jvms on my computer... and something picks
  something it is not supposed to pick...
 
  On Tue, Dec 16, 2014 at 2:06 PM, Andrew Palumbo ap@outlook.com
 wrote:
 
 
 
 
  Should we start a jira for this and ask Anand and the h2o guys to take a
  look?
 
  Date: Wed, 10 Dec 2014 09:49:02 -0800
  Subject: Re: Broken build?
  From: dlie...@gmail.com
  To: dev@mahout.apache.org
 
  No. apparently it is hard to reproduce for everyone else but me.
 
  I tried different jvm, scala and maven versions, to no avail. And
  actually
  i do have it on multiple computers that all produce that error.
 
  At this point my best guess is it is some extra weird and unobvious
  compatibility issue with h20 or one of its transitive dependency
  artifacts.
 
  On Tue, Dec 9, 2014 at 5:32 PM, Andrew Musselman 
  andrew.mussel...@gmail.com
  wrote:
 
  Has anyone from h2o looked at it?
 
  Are we doing much with that module?
 
  On Tue, Dec 9, 2014 at 5:24 PM, Dmitriy Lyubimov dlie...@gmail.com
  wrote:
 
  yes i have been seeing this exact thing for a long time now, but no
  one
  else could reproduce (CI builds pass anyway), and i was unable to
  resolve
  on my own, so i ended up just throwing out h2o module from my
  compilation
  routine.
 
  -d
 
  On Tue, Dec 9, 2014 at 5:13 PM, Andrew Musselman 
  andrew.mussel...@gmail.com
  wrote:
 
  I've run mvn clean after pulling fresh from master and have gotten
  this
  error repeatably; anyone else seeing this problem?
 
  [INFO]
 
  [INFO]
  
  [INFO] Building Mahout H2O backend 1.0-SNAPSHOT
  [INFO]
  
  [WARNING] The POM for ai.h2o:h2o-core:jar:0.1.5 is invalid,
  transitive
  dependencies (if any) will not be available, enable debug logging
  for
  more
  details
  [INFO]
  [INFO] --- build-helper-maven-plugin:1.8:add-source (add-source) @
  mahout-h2o ---
  [INFO] Source directory:
  /home/akm/mahout/h2o/target/generated-sources/mahout added.
  [INFO]
  [INFO] --- build-helper-maven-plugin:1.8:add-test-source
  (add-test-source)
  @ mahout-h2o ---
  [INFO] Test Source directory:
  /home/akm/mahout/h2o/target/generated-test-sources/mahout added.
  [INFO]
  [INFO] --- maven-resources-plugin:2.6:resources
  (default-resources) @
  mahout-h2o ---
  [INFO] Using 'UTF-8' encoding to copy filtered resources.
  [INFO] skip non existing resourceDirectory
  /home/akm/mahout/h2o/src/main/resources
  [INFO]
  [INFO] --- maven-scala-plugin:2.15.2:add-source
  (scala-compile-first) @
  mahout-h2o ---
  [INFO] Add Source directory: /home/akm/mahout/h2o/src/main/scala
  [INFO] Add Test Source directory:
  /home/akm/mahout/h2o/src/test/scala
  [INFO]
  [INFO] --- maven-scala-plugin:2.15.2:compile (scala-compile-first)
  @
  mahout-h2o ---
  [INFO] Checking for multiple versions of scala
  [WARNING] Invalid POM for ai.h2o:h2o-core:jar:0.1.5, transitive
  dependencies (if any) will not be available, enable debug logging
  for
  more
  details
  [WARNING]  Expected all dependencies to require Scala version:
  2.10.4
  [WARNING]  com.github.scopt:scopt_2.10:3.2.0 requires scala
  version:
  2.10.3
  [WARNING] Multiple versions of scala libraries detected!
  [INFO] includes = [**/*.scala,**/*.java,]
  [INFO] excludes = []
  [INFO] /home/akm/mahout/h2o/src/main/java:-1: info: compiling
  [INFO] /home/akm/mahout/h2o/src/main/scala:-1: info: compiling
  [INFO] Compiling 28 source files to
  /home/akm/mahout/h2o/target/classes
  at
  1418173188077
  [ERROR] error: error while loading root, error in opening zip
  file
  [ERROR] error: scala.reflect.internal.MissingRequirementError:
  object
  scala.runtime in compiler mirror not found.
  [ERROR] at
 
 scala.reflect.internal.MissingRequirementError$.signal(MissingRequirementError.scala:16)
  [ERROR] at
 
 

Re: Hadoop 2 support in a real release?

[Stevo Slavić]

I don't like profiles - they complicate things (imagine what release
process would look like, with proper versioning and tagging), and profiles
are not as transparent as other options.

I prefer using assembly per classifier, or having separate (sub)modules
with different dependencies. Then a release of all of the variants
(complete project) would be a single run, each would have clean classpath,
and we'd have easier to comprehend project structure.

Kind regards,
Stevo Slavic


On Fri, May 23, 2014 at 7:27 PM, Ted Dunning ted.dunn...@gmail.com wrote:

 Regarding mechanics, the fact that we have profiles available to do the
 build already should make the process very simple ... roughly just adding
 -Phadoop2 or some such.  Internally, it is setting a few symbols and
 tweaking the dependencies slightly.




 On Fri, May 23, 2014 at 10:21 AM, Dmitriy Lyubimov dlie...@gmail.com
 wrote:

  +1 for something like that. Again, spark just makes tons of binary
 releases
  bound to a specific flavor of H-1 or H-2 including CDH etc.
 
  Not sure if it is totally feasible with just build techniques (the
  ubiquitous #ifdef macros immediately spring up in mind, something i am
  totally not missing in java) but if it is, it is the way to go.
 
 
 
  On Fri, May 23, 2014 at 6:49 AM, Gokhan Capan gkhn...@gmail.com wrote:
 
   My vote would be releasing mahout with hadoop1 and hadoop2 classifiers
  
   Gokhan
  
  
   On Fri, May 23, 2014 at 4:43 PM, Sebastian Schelter 
   ssc.o...@googlemail.com
wrote:
  
Big +1
Am 23.05.2014 15:33 schrieb Ted Dunning ted.dunn...@gmail.com:
   
 What do folks think about spinning out a new version of 0.9 that
 only
 changes which version of Hadoop the build uses?

 There have been quite a few questions lately on this topic.

 My suggestion would be that we use minor version numbering to
  maintain
this
 and the normal 0.9 release simultaneously if we decide to do a bug
  fix
 release.

 Any thoughts?

   
  
 

Re: Build failed in Jenkins: Mahout-Quality #2614

[Stevo Slavić]

Hello team,

Mahout-Quality build is failing because it is run with java 8 (I guess 1.8
is required by our Mahout-Quality job, or default one is used which on
ubuntu1 machine, where this particular execution was run, is 1.8, as shown
by ubuntu1 sys info
https://builds.apache.org/computer/ubuntu1/systemInfowith 1.8 as
java.version system property value), and there is still no
findbugs release compatible with jdk 8 (see
https://sourceforge.net/p/findbugs/bugs/1162/ and
http://findbugs.sourceforge.net/downloads.html ).

One option is to change Mahout-Quality build job definition to execute
using jdk 1.7, until findbugs 3.0 is released. Anyone with enough
privileges to make this change?
Other option, if jdk 1.8 is a must for something else, is to temporarily
skip findbugs-maven-plugin execution, in root pom (skiptrue/skip).

Kind regards,
Stevo Slavic


On Fri, May 23, 2014 at 2:12 AM, Apache Jenkins Server 
jenk...@builds.apache.org wrote:

 See https://builds.apache.org/job/Mahout-Quality/2614/

 --
 [...truncated 7508 lines...]
 }

 Q=
 {
   0  = {0:0.40273861426601687,1:-0.9153150324187648}
   1  = {0:0.9153150324227656,1:0.40273861426427493}
 }
  [32m- C = A %*% B mapBlock {} [0m
  [32m- C = A %*% B incompatible B keys [0m
 35578 [ScalaTest-main-running-RLikeDrmOpsSuite] DEBUG
 org.apache.mahout.sparkbindings.blas.AtB$  - A and B for A'B are not
 identically partitioned, performing inner join.
  [32m- C = At %*% B , join [0m
 37019 [ScalaTest-main-running-RLikeDrmOpsSuite] DEBUG
 org.apache.mahout.sparkbindings.blas.AtB$  - A and B for A'B are not
 identically partitioned, performing inner join.
  [32m- C = At %*% B , join, String-keyed [0m
 38443 [ScalaTest-main-running-RLikeDrmOpsSuite] DEBUG
 org.apache.mahout.sparkbindings.blas.AtB$  - A and B for A'B are
 identically distributed, performing row-wise zip.
  [32m- C = At %*% B , zippable, String-keyed [0m
 {
   2  = {0:62.0,1:86.0,3:132.0,2:115.0}
   1  = {0:50.0,1:69.0,3:105.0,2:92.0}
   3  = {0:74.0,1:103.0,3:159.0,2:138.0}
   0  = {0:26.0,1:35.0,3:51.0,2:46.0}
 }
  [32m- C = A %*% inCoreB [0m
 {
   0  = {0:26.0,1:35.0,2:46.0,3:51.0}
   1  = {0:50.0,1:69.0,2:92.0,3:105.0}
   2  = {0:62.0,1:86.0,2:115.0,3:132.0}
   3  = {0:74.0,1:103.0,2:138.0,3:159.0}
 }
  [32m- C = inCoreA %*%: B [0m
 42519 [ScalaTest-main-running-RLikeDrmOpsSuite] DEBUG
 org.apache.mahout.sparkbindings.blas.AtA$  - Applying slim A'A.
  [32m- C = A.t %*% A [0m
 44000 [ScalaTest-main-running-RLikeDrmOpsSuite] DEBUG
 org.apache.mahout.sparkbindings.blas.AtA$  - Applying non-slim non-graph
 A'A.
 75471 [ScalaTest-main-running-RLikeDrmOpsSuite] DEBUG
 org.apache.mahout.sparkbindings  - test done.
  [32m- C = A.t %*% A fat non-graph [0m
 76723 [ScalaTest-main-running-RLikeDrmOpsSuite] DEBUG
 org.apache.mahout.sparkbindings.blas.AtA$  - Applying slim A'A.
  [32m- C = A.t %*% A non-int key [0m
  [32m- C = A + B [0m
  [32m- C = A + B side test 1 [0m
  [32m- C = A + B side test 2 [0m
  [32m- C = A + B side test 3 [0m
 ArrayBuffer(0, 1, 2, 3, 4)
 ArrayBuffer(0, 1, 2, 3, 4)
  [32m- general side [0m
  [32m- Ax [0m
  [32m- A'x [0m
  [32m- colSums, colMeans [0m
  [36mRun completed in 1 minute, 35 seconds. [0m
  [36mTotal number of tests run: 38 [0m
  [36mSuites: completed 9, aborted 0 [0m
  [36mTests: succeeded 38, failed 0, canceled 0, ignored 0, pending 0 [0m
  [32mAll tests passed. [0m
 [INFO]
 [INFO] --- build-helper-maven-plugin:1.8:remove-project-artifact
 (remove-old-mahout-artifacts) @ mahout-spark ---
 [INFO] /home/jenkins/.m2/repository/org/apache/mahout/mahout-spark removed.
 [INFO]
 [INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ mahout-spark ---
 [INFO] Building jar: 
 https://builds.apache.org/job/Mahout-Quality/2614/artifact/spark/target/mahout-spark-1.0-SNAPSHOT.jar
 
 [INFO]
 [INFO] --- maven-jar-plugin:2.4:test-jar (default) @ mahout-spark ---
 [INFO] Building jar: 
 https://builds.apache.org/job/Mahout-Quality/2614/artifact/spark/target/mahout-spark-1.0-SNAPSHOT-tests.jar
 
 [INFO]
 [INFO] --- maven-source-plugin:2.2.1:jar-no-fork (attach-sources) @
 mahout-spark ---
 [INFO] Building jar: 
 https://builds.apache.org/job/Mahout-Quality/2614/artifact/spark/target/mahout-spark-1.0-SNAPSHOT-sources.jar
 
 [INFO]
 [INFO] --- maven-install-plugin:2.5.1:install (default-install) @
 mahout-spark ---
 [INFO] Installing 
 https://builds.apache.org/job/Mahout-Quality/2614/artifact/spark/target/mahout-spark-1.0-SNAPSHOT.jar
 to
 /home/jenkins/.m2/repository/org/apache/mahout/mahout-spark/1.0-SNAPSHOT/mahout-spark-1.0-SNAPSHOT.jar
 [INFO] Installing 
 https://builds.apache.org/job/Mahout-Quality/ws/spark/pom.xml to
 /home/jenkins/.m2/repository/org/apache/mahout/mahout-spark/1.0-SNAPSHOT/mahout-spark-1.0-SNAPSHOT.pom
 [INFO] Installing 
 https://builds.apache.org/job/Mahout-Quality/2614/artifact/spark/target/mahout-spark-1.0-SNAPSHOT-tests.jar
 to
 

Re: VOTE: moving commits to git-wp.o.a github PR features.

[Stevo Slavić]

+1


On Mon, May 19, 2014 at 5:21 PM, Grant Ingersoll gsing...@apache.orgwrote:

 +1

 On May 16, 2014, at 2:02 PM, Dmitriy Lyubimov dlie...@gmail.com wrote:

  Hi,
 
  I would like to initiate a procedural vote moving to git as our primary
  commit system, and using github PRs as described in Jake Farrel's email
 to
  @dev [1]
 
  [1]
 
 https://blogs.apache.org/infra/entry/improved_integration_between_apache_and
 
  If voting succeeds, i will file a ticket with infra to commence necessary
  changes and to move our project to git-wp as primary source for commits
 as
  well as add github integration features [1]. (I assume pure git commits
  will be required after that's done, with no svn commits allowed).
 
  The motivation is to engage GIT and github PR features as described, and
  avoid git mirror history messes like we've seen associated with
 authors.txt
  file fluctations.
 
  PMC and committers have binding votes, so please vote. Lazy consensus
 with
  minimum 3 +1 votes. Vote will conclude in 96 hours to allow some extra
 time
  for weekend (i.e. Tuesday afternoon PST) .
 
  here is my +1
 
  -d

 
 Grant Ingersoll | @gsingers
 http://www.lucidworks.com

UploadedDRM dir in mahout-spark root

[Stevo Slavić]

Hello team,

Thought it was just me, but it's on Jenkins too (see
https://builds.apache.org/view/All/job/mahout-nightly/ws/trunk/spark/ ) -
running build with tests creates UploadedDRM directory in the root of
mahout-spark module. DrmLikeSuite might be likely cause/producer.

Kind regards,
Stevo Slavic

Re: Mahout 0.9 Release

[Stevo Slavić]

+1


On Wed, Jan 29, 2014 at 10:56 PM, Shannon Quinn squ...@gatech.edu wrote:

 LGTM


 On 1/29/14, 4:27 PM, peng wrote:

 +1, can't see a bad side.

 On Wed 29 Jan 2014 11:33:02 AM EST, Suneel Marthi wrote:

 +1 from me





 On Wednesday, January 29, 2014 8:58 AM, Sebastian Schelter 
 s...@apache.org wrote:

 +1


 On 01/29/2014 05:25 AM, Andrew Musselman wrote:

 Looks good.

 +1


 On Tue, Jan 28, 2014 at 8:07 PM, Andrew Palumbo ap@outlook.com
 wrote:

  a), b), c), d) all passed here.

 CosineDistance of clustered points from cluster-reuters.sh -1 kmeans
 were
 within the range [0,1].

  Date: Tue, 28 Jan 2014 16:45:42 -0800
 From: suneel_mar...@yahoo.com
 Subject: Mahout 0.9 Release
 To: u...@mahout.apache.org; dev@mahout.apache.org

 Fixed the issues that were reported with Clustering code this past
 week,

 upgraded codebase to Lucene 4.6.1 that was released today.


 Here's the URL for the 0.9 release in staging:-

  https://repository.apache.org/content/repositories/
 orgapachemahout-1004/org/apache/mahout/mahout-distribution/0.9/


 The artifacts have been signed with the following key:
 https://people.apache.org/keys/committer/smarthi.asc

 Please:-
 a) Verify that u can unpack the release (tar or zip)
 b) Verify u r able to compile the distro
 c)  Run through the unit tests: mvn clean test
 d) Run the example scripts under $MAHOUT_HOME/examples/bin. Please run

 through all the different options in each script.


 Need a minimum of 3 '+1' votes from PMC for the release to be
 finalized.

Re: Build failed in Jenkins: Mahout-Examples-Classify-20News #414

[Stevo Slavić]

Odd, apart from being run on different Jenkins nodes and few comments
added, this failed build and successful one that followed have no other
(currently known to me) differences. TestNewsGroups might be unstable. Will
have to check it later.

Kind regards,
Stevo


On Mon, Jan 27, 2014 at 3:11 AM, Apache Jenkins Server 
jenk...@builds.apache.org wrote:

 See 
 https://builds.apache.org/job/Mahout-Examples-Classify-20News/414/changes

 Changes:

 [sslavic] MAHOUT-1399: Placed changelog entry on appropriate spot, sorted
 by Jira issue number

 [sslavic] MAHOUT-1399: Fixed multiple slf4j bindings when running Mahout
 examples issue

 --
 [...truncated 2421 lines...]
 [INFO] Compiling 83 source files to 
 https://builds.apache.org/job/Mahout-Examples-Classify-20News/ws/trunk/examples/target/classes
 
 [INFO]
 [INFO] --- maven-resources-plugin:2.6:testResources
 (default-testResources) @ mahout-examples ---
 [INFO] Using 'UTF-8' encoding to copy filtered resources.
 [INFO] Copying 4 resources
 [INFO]
 [INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @
 mahout-examples ---
 [INFO] Changes detected - recompiling the module!
 [INFO] Compiling 5 source files to 
 https://builds.apache.org/job/Mahout-Examples-Classify-20News/ws/trunk/examples/target/test-classes
 
 [INFO]
 [INFO] --- maven-surefire-plugin:2.16:test (default-test) @
 mahout-examples ---
 [INFO] Tests are skipped.
 [INFO]
 [INFO] --- build-helper-maven-plugin:1.8:remove-project-artifact
 (remove-old-mahout-artifacts) @ mahout-examples ---
 [INFO] /home/jenkins/.m2/repository/org/apache/mahout/mahout-examples
 removed.
 [INFO]
 [INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ mahout-examples ---
 [INFO] Building jar: 
 https://builds.apache.org/job/Mahout-Examples-Classify-20News/ws/trunk/examples/target/mahout-examples-0.9-SNAPSHOT.jar
 
 [INFO]
 [INFO] --- maven-dependency-plugin:2.8:copy-dependencies
 (copy-dependencies) @ mahout-examples ---
 [INFO] Copying xmlpull-1.1.3.1.jar to 
 https://builds.apache.org/job/Mahout-Examples-Classify-20News/ws/trunk/examples/target/dependency/xmlpull-1.1.3.1.jar
 
 [INFO] Copying xpp3_min-1.1.4c.jar to 
 https://builds.apache.org/job/Mahout-Examples-Classify-20News/ws/trunk/examples/target/dependency/xpp3_min-1.1.4c.jar
 
 [INFO] Copying lucene-highlighter-4.6.0.jar to 
 https://builds.apache.org/job/Mahout-Examples-Classify-20News/ws/trunk/examples/target/dependency/lucene-highlighter-4.6.0.jar
 
 [INFO] Copying mahout-math-0.9-SNAPSHOT-tests.jar to 
 https://builds.apache.org/job/Mahout-Examples-Classify-20News/ws/trunk/examples/target/dependency/mahout-math-0.9-SNAPSHOT-tests.jar
 
 [INFO] Copying lucene-facet-4.6.0.jar to 
 https://builds.apache.org/job/Mahout-Examples-Classify-20News/ws/trunk/examples/target/dependency/lucene-facet-4.6.0.jar
 
 [INFO] Copying objenesis-1.3.jar to 
 https://builds.apache.org/job/Mahout-Examples-Classify-20News/ws/trunk/examples/target/dependency/objenesis-1.3.jar
 
 [INFO] Copying stax-api-1.0.1.jar to 
 https://builds.apache.org/job/Mahout-Examples-Classify-20News/ws/trunk/examples/target/dependency/stax-api-1.0.1.jar
 
 [INFO] Copying jackson-core-asl-1.9.12.jar to 
 https://builds.apache.org/job/Mahout-Examples-Classify-20News/ws/trunk/examples/target/dependency/jackson-core-asl-1.9.12.jar
 
 [INFO] Copying commons-net-1.4.1.jar to 
 https://builds.apache.org/job/Mahout-Examples-Classify-20News/ws/trunk/examples/target/dependency/commons-net-1.4.1.jar
 
 [INFO] Copying lucene-core-4.6.0.jar to 
 https://builds.apache.org/job/Mahout-Examples-Classify-20News/ws/trunk/examples/target/dependency/lucene-core-4.6.0.jar
 
 [INFO] Copying hadoop-core-1.2.1.jar to 
 https://builds.apache.org/job/Mahout-Examples-Classify-20News/ws/trunk/examples/target/dependency/hadoop-core-1.2.1.jar
 
 [INFO] Copying jakarta-regexp-1.4.jar to 
 https://builds.apache.org/job/Mahout-Examples-Classify-20News/ws/trunk/examples/target/dependency/jakarta-regexp-1.4.jar
 
 [INFO] Copying spatial4j-0.3.jar to 
 https://builds.apache.org/job/Mahout-Examples-Classify-20News/ws/trunk/examples/target/dependency/spatial4j-0.3.jar
 
 [INFO] Copying lucene-benchmark-4.6.0.jar to 
 https://builds.apache.org/job/Mahout-Examples-Classify-20News/ws/trunk/examples/target/dependency/lucene-benchmark-4.6.0.jar
 
 [INFO] Copying commons-beanutils-1.7.0.jar to 
 https://builds.apache.org/job/Mahout-Examples-Classify-20News/ws/trunk/examples/target/dependency/commons-beanutils-1.7.0.jar
 
 [INFO] Copying easymock-3.2.jar to 
 https://builds.apache.org/job/Mahout-Examples-Classify-20News/ws/trunk/examples/target/dependency/easymock-3.2.jar
 
 [INFO] Copying log4j-1.2.17.jar to 
 https://builds.apache.org/job/Mahout-Examples-Classify-20News/ws/trunk/examples/target/dependency/log4j-1.2.17.jar
 
 [INFO] Copying jersey-server-1.8.jar to 
 https://builds.apache.org/job/Mahout-Examples-Classify-20News/ws/trunk/examples/target/dependency/jersey-server-1.8.jar
 
 

Re: [jira] [Commented] (MAHOUT-1397) mahaout-math-scala/pom.xml not readable

[Stevo Slavić]

See http://scala-ide.org/docs/user/gettingstarted.html and especially
http://scala-ide.org/docs/user/gettingstarted.html#Import_a_Maven_project

Kind regards,
Stevo


On Mon, Jan 20, 2014 at 8:09 AM, Maruf Aytekin (JIRA) j...@apache.orgwrote:


 [
 https://issues.apache.org/jira/browse/MAHOUT-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13876197#comment-13876197]

 Maruf Aytekin commented on MAHOUT-1397:
 ---

 Any idea how resolve this issue with eclipse without changing
 configuration of the plugin?

  mahaout-math-scala/pom.xml not readable
  ---
 
  Key: MAHOUT-1397
  URL: https://issues.apache.org/jira/browse/MAHOUT-1397
  Project: Mahout
   Issue Type: Bug
   Components: Math
 Affects Versions: 1.0
  Environment: Windows 7 Professional 64 bit
  Eclipse:
  Version: Kepler Service Release 1
  Build id: 20130919-0819
  maven 3.0.5
  Java: jdk1.6.0_45
 Reporter: Maruf Aytekin
 Assignee: Dmitriy Lyubimov
   Labels: maven
  Fix For: 1.0
 
 
  maven-scala-plugin in mahaout-math-scala/pom.xml gives an error.
  {code}
plugin
groupIdorg.scala-tools/groupId
artifactIdmaven-scala-plugin/artifactId
executions
execution
goals
 
 goalcompile/goal
 
 goaltestCompile/goal
/goals
/execution
/executions
configuration
 
 sourceDirsrc/main/scala/sourceDir
jvmArgs
jvmArg-Xms64m/jvmArg
jvmArg-Xmx1024m/jvmArg
/jvmArgs
/configuration
/plugin
  {code}
  Error displayed:
  {quote}
  Multiple annotations found at this line:
- Plugin execution not covered by lifecycle configuration:
 org.scala-tools:maven-scala-plugin:2.15.2:compile (execution: default,
 phase: compile)
- Plugin execution not covered by lifecycle configuration:
 org.scala-tools:maven-scala-plugin:2.15.2:testCompile (execution: default,
 phase: test-
 compile)
  {quote}



 --
 This message was sent by Atlassian JIRA
 (v6.1.5#6160)

Re: MAHOUT 0.9 Release - New URL

[Stevo Slavić]

+1 (binding)


On Sun, Jan 19, 2014 at 7:49 PM, Dmitriy Lyubimov dlie...@gmail.com wrote:

 I'll try to test out soon

Re: Happy Holidays!

[Stevo Slavić]

Happy Holidays Everyone!


On Tue, Dec 24, 2013 at 12:28 PM, Frank Scholten fr...@frankscholten.nlwrote:

 Best wishes!


 On Tue, Dec 24, 2013 at 11:11 AM, Sebastian Schelter s...@apache.org
 wrote:

  dito!
 
  On 24.12.2013 11:09, Isabel Drost-Fromm wrote:
  
   I'd like to take some time and wish everyone a Happy Holiday!
   Enjoy the time with your family and friends.
  
   Thank you all for your contributions and work on Mahout. Looking
   forward to an exciting 2014.
  
   Isabel
  
 
 

Re: Welcome to Frank Scholten as new Mahout committer

[Stevo Slavić]

Congrats and welcome Frank!


On Tue, Dec 3, 2013 at 2:34 PM, Gokhan Capan gkhn...@gmail.com wrote:

 Congratulations, Frank!

 Gokhan


 On Tue, Dec 3, 2013 at 3:27 PM, Isabel Drost-Fromm isa...@apache.org
 wrote:

 
  Hi,
 
  this is to announce that the Project Management Committee (PMC) for
 Apache
  Mahout has asked Frank Scholten to become committer and we are pleased to
  announce that he has accepted.
 
  Being a committer enables easier contribution to the project since in
  addition
  to posting patches on JIRA it also gives write access to the code
  repository.
  That also means that now we have yet another person who can commit
 patches
  submitted by others to our repo *wink*
 
  Frank, you've been following the project for quite some time now -
  contributing
  valuable changes over and over again. I certainly look forward to working
  with you in the future. Welcome!
 
 
  Isabel
 
 
 

Re: Mahout Jira

[Stevo Slavić]

Works for me. Maybe you've been affected by some of the issues from recent
JIRA upgrade (see https://twitter.com/infrabot)
Consider clearing browser cache and cookies, maybe that will help.

Kind regards,
Stevo Slavic.


On Mon, Sep 30, 2013 at 5:27 PM, Suneel Marthi suneel_mar...@yahoo.comwrote:

 JIRA's been down now for sometime, below link is not working.


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

Re: [jira] [Commented] (MAHOUT-1342) Exclude .git/**, Eclipse, and .patch files from Rat check

[Stevo Slavić]

It turns out that useDefaultExcludes actually means exclude using
patterns defined in
http://plexus.codehaus.org/plexus-utils/apidocs/org/codehaus/plexus/util/AbstractScanner.html#DEFAULTEXCLUDES

and has nothing to do with other 3 switches for excluding maven, eclipse,
and idea files.

Those 3 others have patterns which do not match maven, eclipse and idea
files in nested directories. So when excludeSubProjects is false, maven,
eclipse and idea files in submodules get matched.
I've fixed it and attached a patch to previously reported related issue:
https://issues.apache.org/jira/browse/RAT-107

Please consider voting for the issue.

Kind regards,
Stevo Slavić.


On Wed, Sep 25, 2013 at 10:50 AM, Sean Owen sro...@gmail.com wrote:

 I had basically the same question as default excludes did not seem to cover
 as much as I expected. It prints default excludes to the console. At worst
 this is just some extra config, no big harm.
 On Sep 25, 2013 12:44 AM, Stevo Slavic (JIRA) j...@apache.org wrote:

 
  [
 
 https://issues.apache.org/jira/browse/MAHOUT-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13776930#comment-13776930
 ]
 
  Stevo Slavic commented on MAHOUT-1342:
  --
 
  Patch is applied, thanks [~mpercy] for providing it.
 
  Btw, I'm finding [apache-rat-plugin check-mojo docs|
  http://creadur.apache.org/rat/apache-rat-plugin/check-mojo.html] to be
  confusing.
  For parameter {{excludes}} docs state:
  {quote}
  Specifies files, which are excluded in the report. By default, no files
  are excluded.
  {quote}
  While for parameter {{useDefaultExcludes}} of the same mojo docs state:
  {quote}
  Whether to use the default excludes when scanning for files. The default
  excludes are:
  meta data files for version control systems
  temporary files used by Maven, see useMavenDefaultExcludes
  configuration files for Eclipse, see useEclipseDefaultExcludes
  configuration files for IDEA, see useIdeaDefaultExcludes
 
  Default value is: true.
  User property is: rat.useDefaultExcludes.
  {quote}
 
  If {{useDefaultExcludes}} being true by default was respected, I expect
  that we would not have to configure excludes for svn, maven, eclipse and
  idea files. Also I expect that specifying (additional) {{excludes}}
 should
  not be turning off {{useDefaultExcludes}}.
 
   Exclude .git/**, Eclipse, and .patch files from Rat check
   -
  
   Key: MAHOUT-1342
   URL: https://issues.apache.org/jira/browse/MAHOUT-1342
   Project: Mahout
Issue Type: Improvement
Components: build
  Reporter: Mike Percy
  Assignee: Stevo Slavic
  Priority: Minor
   Fix For: 0.9
  
   Attachments: MAHOUT-1342.patch
  
  
   Simple patch to exclude the .git directory, along with Eclipse working
  directory files and patch files from the Rat check so that it can be run
 in
  a developer environment with those impurities present.
 
  --
  This message is automatically generated by JIRA.
  If you think it was sent incorrectly, please contact your JIRA
  administrators
  For more information on JIRA, see:
 http://www.atlassian.com/software/jira
 

javadoc fix left holes

[Stevo Slavić]

Hello team,

Long time ago, back in 2010, there was a commit, r915278, which if I'm not
mistaken left some holes in javadoc of existing classes. Not all classes
survived since then, but there are still quite some with same holes in
javadoc. Here are few affected classes:

Parametered
FileLineIterable
FileLineIterator
UserSimilarity
Rescorer
Recommender
Preference
DataModel
GenericItemSimilarity
AbstractSimilarity
MySQLJDBCDataModel
MySQLBooleanPrefJDBCDataModel
FileDataModel
GenericDataModel
Cache
FastByIDMap
FastIDSet
LongPrimitiveArrayIterator
FastMap
RefreshHelper
RecommenderEvaluator
Refreshable

Typically, javadoc of those classes would have a reference to themselves
with {@link NameOfAGivenClass} and change would just remove the reference
leaving rest of the javadoc sentence incomplete.
There are other type of changes in that commit, some changing javadoc, some
changing code/templates.

Does anyone know was this javadoc change intentional? Or was it an unwanted
accidental change?

Kind regards,
Stevo Slavic.

Re: All links are broken on the Mahout quickstart page

[Stevo Slavić]

https://cwiki.apache.org/confluence/display/MAHOUT/Quickstart


On Wed, Sep 4, 2013 at 7:16 PM, Ravi Mummulla ravi.mummu...@gmail.comwrote:

 All links are broken in https://cwiki.apache.org/MAHOUT/quickstart.html.
 Is
 anyone working on fixing the links or do we have a JIRA open to fix the
 links? If not, I can take it.

 --
 Thanks
 ,
 Ravi

Re: All links are broken on the Mahout quickstart page

[Stevo Slavić]

If I understand well http://www.apache.org/dev/cms.html#confluence-phaseout
 , http://www.apache.org/dev/project-site.html  and
http://www.dankulp.com/blog/2012/03/svnpubsub-for-confluence-sites/ we
should be migrating away from Confluence to svnpubsub and optionally to
Apache CMS.


On Wed, Sep 4, 2013 at 7:51 PM, Sebastian Schelter s...@apache.org wrote:

 Great. A Jira would be very helpful to track this.


 2013/9/4 Ravi Mummulla ravi.mummu...@gmail.com

  I can take a shot at this. Do we need a JIRA filed?​
 
 
  On Wed, Sep 4, 2013 at 10:35 AM, Sebastian Schelter s...@apache.org
  wrote:
 
   Does anyone know how to fix this stuff? Its super-important to get our
  wiki
   to a useable state again.
  
  
   2013/9/4 Andrew Musselman andrew.mussel...@gmail.com
  
Or rather put in a 301(permanantly moved) redirect so any old links
 end
   up
in the right place?
   
   
On Wed, Sep 4, 2013 at 10:22 AM, Andrew Musselman 
andrew.mussel...@gmail.com wrote:
   
 Can we take down the other one?  Been a few people caught up by
 this
 problem recently.


 On Wed, Sep 4, 2013 at 10:20 AM, Stevo Slavić ssla...@gmail.com
   wrote:

 https://cwiki.apache.org/confluence/display/MAHOUT/Quickstart


 On Wed, Sep 4, 2013 at 7:16 PM, Ravi Mummulla 
   ravi.mummu...@gmail.com
 wrote:

  All links are broken in
https://cwiki.apache.org/MAHOUT/quickstart.html
 .
  Is
  anyone working on fixing the links or do we have a JIRA open to
  fix
the
  links? If not, I can take it.
 
  --
  Thanks
  ,
  Ravi
 



   
  
 
 
 
  --
  Thanks.
 

Re: You are invited to Apache Mahout meet-up

[Stevo Slavić]

Retweeted meetup invite. Have fun!

Kind regards,
Stevo Slavic.


On Thu, Aug 22, 2013 at 8:34 AM, Ted Dunning ted.dunn...@gmail.com wrote:

 Very cool.

 Would love to see folks turn out for this.


 On Wed, Aug 21, 2013 at 9:38 PM, Ellen Friedman
 b.ellen.fried...@gmail.comwrote:

  The Apache Mahout user group has been re-activated. If you are in the Bay
  Area in California, join us on Aug 27 (Redwood City).
 
  Sebastian Schelter will be the main speaker, talking about new directions
  with Mahout recommendation. Grant Ingersoll, Ted Dunning and I be there
 to
  do a short introduction for the meet-up and update on the 0.8 release.
 
  Here's the link to rsvp: http://bit.ly/16K32hg
 
  Hope you can come, and please spread the word.
 
  Ellen
 

Re: apache-math dependency

[Stevo Slavić]

There are 30 matches when searching for org.apache.commons.math3 in
Mahout java files.


On Fri, Aug 9, 2013 at 8:34 PM, Dmitriy Lyubimov dlie...@gmail.com wrote:

 FYI SSVD does not have that dependency anymore (thanks to fixes to
 EigenSolver in Mahout). If there are no more methods using it, it can be
 deleted from pom.

 -d

Re: SequenceFilesFromMailArchivesTest.testSequential failing

[Stevo Slavić]

Issue created in JIRA: https://issues.apache.org/jira/browse/MAHOUT-1302


On Mon, Aug 5, 2013 at 12:49 AM, Ted Dunning ted.dunn...@gmail.com wrote:

 I think that deterministicizing (new word alert) the order is a good thing.


 On Sun, Aug 4, 2013 at 3:42 PM, Suneel Marthi suneel_mar...@yahoo.com
 wrote:

  Stevo,
 
  I'll fix this.
 
 
 
 
 
 
  
   From: Stevo Slavić ssla...@gmail.com
  To: dev@mahout.apache.org
  Sent: Sunday, August 4, 2013 6:13 PM
  Subject: SequenceFilesFromMailArchivesTest.testSequential failing
 
 
  Hello team,
 
  SequenceFilesFromMailArchivesTest.testSequential is failing only on
 ubuntu3
  and ubuntu6 Jenkins nodes. Because of that, MahoutQuality job builds
 either
  fail or are successful depending on where they get run.
 
  Test fails because it expects entries in chunk-0 SequenceFile to be in
  specific order, but that order is not guaranteed because of the way the
  chunk-0 is created/filled - SequenceFilesFromMailArchives traverses input
  using Java's
 
  File[] java.io.File.listFiles(FileFilter filter)
 
  which does not guarantee order of files/directories.
 
  Unless we want in SequenceFileIterator to guarantee order by sorting,
 test
  needs to be changed to verify presence of given files and their content,
  but not their exact order.
 
  Kind regards,
  Stevo Slavic.
 

SequenceFilesFromMailArchivesTest.testSequential failing

[Stevo Slavić]

Hello team,

SequenceFilesFromMailArchivesTest.testSequential is failing only on ubuntu3
and ubuntu6 Jenkins nodes. Because of that, MahoutQuality job builds either
fail or are successful depending on where they get run.

Test fails because it expects entries in chunk-0 SequenceFile to be in
specific order, but that order is not guaranteed because of the way the
chunk-0 is created/filled - SequenceFilesFromMailArchives traverses input
using Java's

File[] java.io.File.listFiles(FileFilter filter)

which does not guarantee order of files/directories.

Unless we want in SequenceFileIterator to guarantee order by sorting, test
needs to be changed to verify presence of given files and their content,
but not their exact order.

Kind regards,
Stevo Slavic.

Re: Jenkins build is back to normal : Mahout-Quality #2166

[Stevo Slavić]

Mahout build is oscillating because test SearchSanityTest.testRemoval is
oscillating. When it fails, it fails for LocalitySensitiveHashSearch
searcher only.

I've run this test couple of times in IDE, most of the time it's
successful, but occasionally it fails.
With breakpoint on line 166, and breakpoint condition
Math.abs(r.get(0).getValue().minus(r0.get(1).getValue()).norm (1) - 0) 
1.0e-8

one of the failures had following variable state:

x =
[{0:0.8709558437987425,1:-0.5375954118626808,2:-1.2425196954788476,3:-0.5963352681084106,4:1.0979837347756136,5:2.304185373890536,6:0.25793628051644957,7:-1.134330442919324,8:1.597646398122005,9:0.8298520595445593,10:0.6261553451858568,11:-1.1887039545363631,12:0.5869327492264573,13:0.28388860533192856,14:-1.3022503895547264,15:0.6010871637821463,16:0.746145422813361,17:1.1176489418882314,18:0.12290804380398342,19:-0.7023943607753743},
{0:-0.1273613082447137,1:0.5212805226355095,2:-1.3441436944174596,3:0.726170066826851,4:0.771368418859047,5:0.01430669137394401,6:-1.0322788220328099,7:0.9800796113367815,8:1.0860923051790574,9:-0.5343931502079539,10:-0.8687519451795613,11:-0.4882818867652608,12:0.5763217636362794,13:-1.5319064044424902,14:1.5805638933745385,15:1.1042306701927427,16:0.8039127800857652,17:0.06535662950296073,18:0.16616159580914874,19:0.547757546046}]

r0 =
[0]={0:0.8709558437987425,1:-0.5375954118626808,2:-1.2425196954788476,3:-0.5963352681084106,4:1.0979837347756136,5:2.304185373890536,6:0.25793628051644957,7:-1.134330442919324,8:1.597646398122005,9:0.8298520595445593,10:0.6261553451858568,11:-1.1887039545363631,12:0.5869327492264573,13:0.28388860533192856,14:-1.3022503895547264,15:0.6010871637821463,16:0.746145422813361,17:1.1176489418882314,18:0.12290804380398342,19:-0.7023943607753743}
weight 0

[1]=
{0:-0.20483940907349352,1:0.11976413233109141,2:-0.446414355106293,3:-1.7367952330678786,4:0.38238934234736355,5:0.6975417327142289,6:0.3373969986394851,7:-1.4185380951449957,8:0.9265441416353332,9:-0.025206163271980428,10:0.4669637747091974,11:-0.5737988084119644,12:0.41358433275511775,13:0.177386844272387,14:-1.346843287707939,15:0.3409985498083112,16:0.273396568351321,17:0.535280502127145,18:-0.903059026848925,19:-0.8379568998394694}
weight 3.1676437428926834

[2]=
{0:0.8249102943426255,1:-1.3029973079099118,2:-0.6637757770704698,3:-0.6872922698053289,4:0.8694850261953001,5:2.0098551642810314,6:0.6329036548247581,7:-0.7020002439436349,8:1.1002127917459246,9:0.9940539101040394,10:1.2930352335192057,11:1.2969741235560996,12:0.5655788109525552,13:0.3352483698563293,14:-0.07778210967771995,15:0.21446631032850147,16:0.19873363445983003,17:-0.299301008269592,18:-0.3475216337380752,19:-0.6413611008146741}
weight 3.5326455510724935

[3]=
{0:1.0213160889001143,1:-0.16764174017854278,2:-0.8248105102044536,3:0.548181150451324,4:1.2389184164722173,5:0.2894603912982171,6:0.4878734279209343,7:-0.880556725985863,8:1.82674712512,9:-0.4546221613342545,10:0.3506596412191718,11:-0.6414730833164245,12:-0.13282164842381447,13:0.45057016018778245,14:-1.5111928535925796,15:0.06638106718301788,16:0.08281114228255751,17:-0.6421195739702901,18:-0.5493966162085773,19:-0.007304932871986156}
weight 3.642139801900397
...

r =
[0]=
{0:0.8249102943426255,1:-1.3029973079099118,2:-0.6637757770704698,3:-0.6872922698053289,4:0.8694850261953001,5:2.0098551642810314,6:0.6329036548247581,7:-0.7020002439436349,8:1.1002127917459246,9:0.9940539101040394,10:1.2930352335192057,11:1.2969741235560996,12:0.5655788109525552,13:0.3352483698563293,14:-0.07778210967771995,15:0.21446631032850147,16:0.19873363445983003,17:-0.299301008269592,18:-0.3475216337380752,19:-0.6413611008146741}
weight 3.5326455510724935

[1]=
{0:1.0213160889001143,1:-0.16764174017854278,2:-0.8248105102044536,3:0.548181150451324,4:1.2389184164722173,5:0.2894603912982171,6:0.4878734279209343,7:-0.880556725985863,8:1.82674712512,9:-0.4546221613342545,10:0.3506596412191718,11:-0.6414730833164245,12:-0.13282164842381447,13:0.45057016018778245,14:-1.5111928535925796,15:0.06638106718301788,16:0.08281114228255751,17:-0.6421195739702901,18:-0.5493966162085773,19:-0.007304932871986156}
weight 3.642139801900397

[2]=
{0:1.6656465845840556,1:0.6717244738768022,2:-0.11589200853467475,3:-1.505832511237,4:-0.6229838627352531,5:0.9744547121420478,6:0.5863699160394856,7:-1.2460776338162076,8:1.7748095928030267,9:0.7468726003405439,10:0.6084109063104702,11:-1.8578009892923697,12:-0.8413781857292507,13:0.6656257410413803,14:-0.6330806168110932,15:0.095425316213816,16:1.208742880515909,17:0.6308515482408196,18:0.8135753619367572,19:0.2227766502790239}
weight 3.7683177596914277

[3]=

solaris1 Jenkins node not enough space issue

[Stevo Slavić]

Hello team,

Mahout builds which run on Jenkins solaris1 node regularly fail. Initially
I thought it had to do with disk footprint of Mahout builds. After a bit of
research I've determined that this is not Mahout build/project specific,
there is a general issue with that Jenkins node - not enough swap space.
To have this handled I've created a bug to infra,
https://issues.apache.org/jira/browse/INFRA-6597
Feel free to vote on the issue.

Kind regards,
Stevo Slavic.

Re: Question on handling Mahout CHANGELOG

[Stevo Slavić]

I've just committed a change, for MAHOUT-1275, and updated CHANGELOG
according to the agreement.

Kind regards,
Stevo Slavic.


On Fri, Jul 26, 2013 at 5:58 PM, Suneel Marthi suneel_mar...@yahoo.comwrote:

 So be it. Thanks Sebastian.




 
  From: Sebastian Schelter s...@apache.org
 To: dev@mahout.apache.org; Suneel Marthi suneel_mar...@yahoo.com
 Sent: Friday, July 26, 2013 11:58 AM
 Subject: Re: Question on handling Mahout CHANGELOG



 I like the first option, thats also what Giraph is doing.




 2013/7/26 Suneel Marthi suneel_mar...@yahoo.com

 Given the Mahout 0.8 has been released, how do we handle the CHANGELOG
 file?
 
 Do we mark 0.8 as Released and start a new 0.9 - unreleased section?
 or
 Do we blow out all entries in present CHANGELOG for 0.8 and start afresh
 for 0.9?
 
 Looking for guidance and what the best practices are to handle this,
 apologize for my ignorance.

Mahout Jenkins builds are not updating JIRA issues because of an authentication problem

[Stevo Slavić]

Log snippet from recent Mahout Quality
buildhttps://builds.apache.org/job/Mahout-Quality/2161/console
:


Error updating JIRA issues. Saving issues for next build.
com.atlassian.jira.rpc.exception.RemoteAuthenticationException:
Attempt to log in user 'hudson' failed. The maximum number of failed
login attempts has been reached. Please log into the application
through the web interface to reset the number of failed login
attempts.



Maybe it's related to recent Apache Infra LDAP issue.

Kind regards,
Stevo Slavic.

mahout-distribution-0.8-src.tar.gz cannot be unpacked on Linux

[Stevo Slavić]

Hello team,

Just like binary distribution couldn't be unpacked (see
MAHOUT-1229https://issues.apache.org/jira/browse/MAHOUT-1229),
I've just discovered that mahout-distribution-0.8-src.tar.gz also cannot be
unpacked (mahout executable cannot be unpacked to bin directory, bin
directory permissions are not set). Zip distribution src archive can be
unpacked.

Fix is trivial, equivalent to the fix for MAHOUT-1229.

Shall we just fix this in 0.9 or release new 0.8 RC with this fixed?

Kind regards,
Stevo Slavic.

Re: [VOTE] Release Mahout 0.8

[Stevo Slavić]

+1


On Thu, Jul 18, 2013 at 8:55 AM, Ted Dunning ted.dunn...@gmail.com wrote:

 +1

 I pointed a project that uses Mahout to this staging repo.  The compile and
 package went properly and my IDE was able to download and attach sources
 correctly.

 I manually pulled down a few artifacts and noodled around in them and they
 seemed good.

 I didn't check signature yet.



 On Tue, Jul 16, 2013 at 1:52 PM, Grant Ingersoll gsing...@apache.org
 wrote:

  Applying a forcing function:
 
  Please vote on releasing the 0.8 artifacts at
 
 https://repository.apache.org/content/repositories/orgapachemahout-113/org/apache/mahout/
  .
 
  Release notes are at
  https://cwiki.apache.org/confluence/display/MAHOUT/Release+0.8
 
  [] +1 Looks good
  [] 0 - No opinion
  [] -1 Don't release
 
  Vote criteria from https://www.apache.org/dev/release.html
 
  What are the ASF requirements on approving a release?
  Votes on whether a package is ready to be released use majority approval
  -- i.e., at least three PMC members must vote affirmatively for release,
  and there must be more positive than negative votes. Releases may not be
  vetoed. Before voting +1 PMC members are required to download the signed
  source code package, compile it as provided, and test the resulting
  executable on their own platform, along with also verifying that the
  package meets the requirements of the ASF policy on releases.
 
  Thanks,
  Grant

Re: mahout-distribution-0.8-src.tar.gz cannot be unpacked on Linux

[Stevo Slavić]

There are more issues with distribution archives (e.g. they contain
unwanted files and directories like modules Maven target directories and
their content).

All of this IMO is minor, including issue with unpacking source tar.gz
archive (there are 3 more source archives in release out of which at least
zip archives can be unpacked, and there is tag in svn too), so these issues
can be solved in next release.


On Thu, Jul 18, 2013 at 8:27 AM, Stevo Slavić ssla...@gmail.com wrote:

 Hello team,

 Just like binary distribution couldn't be unpacked (see 
 MAHOUT-1229https://issues.apache.org/jira/browse/MAHOUT-1229),
 I've just discovered that mahout-distribution-0.8-src.tar.gz also cannot be
 unpacked (mahout executable cannot be unpacked to bin directory, bin
 directory permissions are not set). Zip distribution src archive can be
 unpacked.

 Fix is trivial, equivalent to the fix for MAHOUT-1229.

 Shall we just fix this in 0.9 or release new 0.8 RC with this fixed?

 Kind regards,
 Stevo Slavic.

Re: Jenkins build is back to normal : mahout-nightly » Mahout Integration #1288

[Stevo Slavić]

This one is successful again, but just because it ran on different Jenkins
node (ubuntu1) which had enough disk space, compared to Jenkins node where
it regularly fails (solaris1) which doesn't have that much disk space.

MAHOUT-1275 will help with this but there are more things we can do about
how much disk space each build takes, and reduce disk space footprint of
all of our build jobs.

E.g. for this build job it seems that archiving build artifacts by Jenkins
is turned on - if I'm not mistaken we do not promote Jenkins builds into
releases, or use anything else that could make use of archived build
artifacts, so IMO this archiving can be turned off.

Also, we can in existing build jobs add pre build step (or modify pom to
have a new ci profile and in it), to execute a Maven build which will
cleanup all the previous builds of Mahout from Jenkins node local maven
repository with the help of build helper maven plugin and its
remove-project-artifact goal).
This can be tested on solaris1 Jenkins node, by configuring nightly build
job to temporarily execute only that node only.

What do you guys think of these build improvement ideas? I guess I should
create separate JIRA tickets for these two if they seem reasonable. Who has
necessary rights to make these changes, or how does one get them granted?

Kind regards,
Stevo Slavić.



On Wed, Jul 10, 2013 at 2:03 AM, Apache Jenkins Server 
jenk...@builds.apache.org wrote:

 See 
 https://builds.apache.org/job/mahout-nightly/org.apache.mahout$mahout-integration/1288/
 

Mahout release process

[Stevo Slavić]

This is continuation of my and Grant's discussion on
https://issues.apache.org/jira/browse/MAHOUT-1275 which I believe is better
suited to be continued here on the dev mailing list.

Apologies for my ignorance, if this discussion took place earlier in the
project lifetime.


There is no 0.8 branch here: http://svn.apache.org/viewvc/mahout/branches/
maven-release-plugin:prepare creates a tag only, which (in svn) although
similar to branch, shouldn't be modifiable, and we need it to be modifiable
if something needs to be changed for final 0.8 release, without
stopping/freezing 0.9 development.
Release instructions basically state that if something is wrong with RC
release, to delete RC release (drop staging repo and delete tag from svn),
rollback version changes on trunk (from 0.9-SNAPSHOT back to 0.8-SNAPSHOT),
make a fix on trunk, and prepare/perform RC release again (same 0.8 release
version).
Current 0.8 RC, IMO is not a proper RC - if we need to make a change to it
and release another RC, there would be no obvious distinction between the
two RCs, especially to Maven builds that Mahout users are likely to be
using, so even after second RC they might still be using/testing with the
old one (cached/resolved in their local repo) as Mahout Maven artifact
coordinates didn't change (same 0.8 version for both RCs).

In workflow I mentioned (in MAHOUT-1275 comment) - we'd make 0.8.x branch
(with maven-release-plugin branch goal), then from that branch make 0.8.RC1
release (release:prepare/perform), with 0.8.x branch POMs staying on
0.8-SNAPSHOT; then if something is found to be wrong with 0.8.RC1, we could
modify the branch (merge the change to 0.9-SNAPSHOT on trunk), and make
another 0.8 RC release, but now of 0.8.RC2 version (different Mahout Maven
artifact coordinates), and so on; when 0.8.RCX is acceptable, passes vote,
we'd make another release or promote 0.8.RCX, to 0.8 or 0.8.FINAL. Final
one would be published on release repository, while all the RCs on staging
repo. Before final release, 0.8.x branch would have 0.8-SNAPSHOT version in
POMs. Branch 0.8.x after final release could have 0.8.1-SNAPSHOT version,
for any critical support changes in future, before 0.9 release.
During whole time of forging 0.8 RC and final releases on their own 0.8.x
branch, 0.9-SNAPSHOT development on trunk can go on. Also, there would be
no rollbacks necessary for RC releases (with exception of cases when it's
really necessary, e.g. when release of some RC is incomplete/breaks because
of network failure or something similar). Also tags stay non-modifiable.

I noticed at least one Apache project to follow this release workflow (with
staging RCs with different Maven coordinates, and promoting an RC to final
release), namely on Apache HttpComponents project.

I could understand current release process, if idea is to have all hands
focused on the release while it's being made/tested, and also making it
obvious to community (with absence of branches other than trunk) that there
is no support whatsoever possible/available via minor releases, apart from
changes on trunk and next major release.

Kind regards,
Stevo Slavić.

Re: 0.8 progress

[Stevo Slavić]

 on a real cluster before
  the
 release.
 I will do this for the recommenders code next week.

 --sebastian
 Am 28.06.2013 14:03 schrieb Grant Ingersoll 
   gsing...@apache.org
:

 I should have time next week to do the release, if we can get
   these
 knocked out.  If not next week, the following.

 On Jun 28, 2013, at 5:46 AM, Suneel Marthi 
suneel_mar...@yahoo.com
 wrote:

 1. Could someone look at Mahout-1257? There is a patch
 that's
   been
 submitted but I am not sure if this has been superseded by
  Sean's
 against
 Mahout-1239.
 2. Stevo, I am for fixing the findbugs excludes as part of
 0.8
 release,
 I see that the number of warnings has gone up over the last
 few
builds.
 3. I am more concerned about the cause of the mysterious
  cosmic
rays
 that randomly fail unit tests (since we have moved to running
parallel
 tests).  I see that happening on my local repository too.



 
 From: Stevo Slavić ssla...@gmail.com
 To: dev@mahout.apache.org
 Sent: Friday, June 28, 2013 3:21 AM
 Subject: Re: 0.8 progress


 Well done team!

 Build is unstable, oscillates, IMO regardless of changes
 made.
Judging
 from
 logs I suspect that some of the Jenkins nodes are not
  configured
well,
 /tmp
 directory security related issues, and file size
 constraints.
Could be
 also
 issue with our tests.

 Javadoc was reported earlier not to be OK (not all modules
 in
 aggregated
 javadoc), and code quality reports are not working OK, e.g.
findbugs
 doesn't respect excludes - plan to work on this during
  weekend.

 Do we want to fix these before or after 0.8 release?

 Kind regards,
 Stevo Slavić.


 On Fri, Jun 28, 2013 at 12:32 AM, Robin Anil 
robin.a...@gmail.com
 wrote:
 All Done

 Robin Anil | Software Engineer | +1 312 869 2602 | Google
  Inc.


 On Sun, Jun 23, 2013 at 11:36 PM, Robin Anil 
robin.a...@gmail.com
 wrote:
 I sent the comments. The code is good. But without the
matrix/vector
 input
 we cant ship it in the release. Hope Yiqun and Da Zhang
 can
   make
 those
 changes quickly.


 Robin Anil | Software Engineer | +1 312 869 2602 | Google
  Inc.


 On Sun, Jun 23, 2013 at 8:46 PM, Grant Ingersoll 
 gsing...@apache.org
 wrote:

 I see 1 issue left: MAHOUT-1214.  It is assigned to
 Robin.
Any
 chance
 we
 can finish this up this week?

 -Grant

 On Jun 23, 2013, at 9:26 AM, Suneel Marthi 
 suneel_mar...@yahoo.com
 wrote:

 Finally got to finishing up M-833, the changes can be
reviewed at
 https://reviews.apache.org/r/11774/diff/3/.




 
 From: Grant Ingersoll gsing...@apache.org
 To: dev@mahout.apache.org
 Sent: Tuesday, June 11, 2013 10:09 AM
 Subject: Re: 0.8 progress


 I pushed M-1030 and M-1233.  If we can get M-833 and
  M-1214
in by
 Thursday, I can roll an RC on Thursday.
 -Grant

 On Jun 11, 2013, at 8:56 AM, Grant Ingersoll 
gsing...@apache.org
 wrote:
 Down to 4 issues!  I would say what they are, but JIRA
 is
flaking
 out
 again.
 My instinct is that 1030 and 1233 can be pushed.
 Suneel
   has
been
 working hard to get M-833 in.  Not sure on M-1214, Robin?
 -G

 On Jun 9, 2013, at 6:10 PM, Grant Ingersoll 
gsing...@apache.org
 wrote:
 On Jun 9, 2013, at 6:02 PM, Grant Ingersoll 
 gsing...@apache.org
 wrote:
 M-1067 -- Dmitriy  --  This is an enhancement,
 should
  we
push?
 Looks like this was committed already.


 
 Grant Ingersoll | @gsingers
 http://www.lucidworks.com
 
 Grant Ingersoll | @gsingers
 http://www.lucidworks.com






 
 Grant Ingersoll | @gsingers
 http://www.lucidworks.com






 
 Grant Ingersoll | @gsingers
 http://www.lucidworks.com










   

Grant Ingersoll | @gsingers
http://www.lucidworks.com
   
   
   
   
   
   
  
 

Re: Jenkins build is back to normal : Mahout-Quality #2128

[Stevo Slavić]

Build still seems to be failing (see
https://builds.apache.org/job/mahout-nightly/1286/consoleFull ), maybe just
less frequently.
Will have to look into this, after release.

Kind regards,
Stevo Slavić.


On Sun, Jul 7, 2013 at 11:02 PM, Grant Ingersoll gsing...@apache.orgwrote:


 On Jul 6, 2013, at 4:38 PM, Stevo Slavić ssla...@gmail.com wrote:

  What did the trick (as of r1500216) for last two builds to be successful
  was serializing unit tests. At least some of them it seems are not
 designed
  to run in parallel (they very likely share some state), and they were
  running in parallel (1.5 per CPU core of Jenkins node on which build is
  running), causing each other to fail randomly. Now it's all sequential.

 So, we undid the parallel builds?  Do you have a sense of the ones that
 were causing problems?

 -G

Re: Jenkins build is back to normal : Mahout-Quality #2128

[Stevo Slavić]

Hello team,

Success of that particular build was pure luck. Point of the commit that
triggered the build and several previous commits was to get source code
static analysis checks to work and consistently use custom settings from
buildtools module. E.g. SE_BAD_FIELD rule/check is excluded from findbugs
checks. Before these changes findbugs maven report on Jenkins used to list
that as high prio findbugs
issuehttps://builds.apache.org/job/Mahout-Quality/2118/findbugsResult/HIGH/module.-1810137467/package.-1319752439/in
modules like mahout-core, now
it 
doesn'thttps://builds.apache.org/job/Mahout-Quality/2131/findbugsResult/HIGH/.
I wanted to work on eliminating those quality issues, and found lack of
consistency between Jenkins and IDE annoying enough to go and fix it before
0.8 release, even while on vacation - island of Thassos, Greece, it's nice
here btw, you should all come :-)

What did the trick (as of r1500216) for last two builds to be successful
was serializing unit tests. At least some of them it seems are not designed
to run in parallel (they very likely share some state), and they were
running in parallel (1.5 per CPU core of Jenkins node on which build is
running), causing each other to fail randomly. Now it's all sequential.
Good thing is, that all Mahout build jobs are passing now. Downside is that
build time has increased. It tripled for these two:
https://builds.apache.org/job/Mahout-Quality/buildTimeTrend
https://builds.apache.org/job/Mahout-Trunk/buildTimeTrend

and nightly build took ~7x more time to complete:
https://builds.apache.org/job/mahout-nightly/buildTimeTrend

Mahout-Examples build jobs build times it seems didn't change.

Fast feedback from unit tests IMO is very important, so we should improve
the build time, better sooner than later, through more build script
configuration, but also designing unit tests for parallel execution in mind.

Kind regards,
Stevo Slavić.

On Sat, Jul 6, 2013 at 2:37 AM, Suneel Marthi suneel_mar...@yahoo.comwrote:

 Thanks Stevo.  This could be a dumb question given my complete lack of
 understanding of all things Maven - so what was it that was causing random
 test failures?




 
  From: Ted Dunning ted.dunn...@gmail.com
 To: Mahout Dev List dev@mahout.apache.org
 Sent: Friday, July 5, 2013 8:22 PM
 Subject: Re: Jenkins build is back to normal : Mahout-Quality #2128


 Thank you Stevo!


 On Fri, Jul 5, 2013 at 4:45 PM, Apache Jenkins Server 
 jenk...@builds.apache.org wrote:

  See https://builds.apache.org/job/Mahout-Quality/2128/changes
 
 

Re: 0.8 progress

[Stevo Slavić]

Well done team!

Build is unstable, oscillates, IMO regardless of changes made. Judging from
logs I suspect that some of the Jenkins nodes are not configured well, /tmp
directory security related issues, and file size constraints. Could be also
issue with our tests.

Javadoc was reported earlier not to be OK (not all modules in aggregated
javadoc), and code quality reports are not working OK, e.g. findbugs
doesn't respect excludes - plan to work on this during weekend.

Do we want to fix these before or after 0.8 release?

Kind regards,
Stevo Slavić.


On Fri, Jun 28, 2013 at 12:32 AM, Robin Anil robin.a...@gmail.com wrote:

 All Done

 Robin Anil | Software Engineer | +1 312 869 2602 | Google Inc.


 On Sun, Jun 23, 2013 at 11:36 PM, Robin Anil robin.a...@gmail.com wrote:

  I sent the comments. The code is good. But without the matrix/vector
 input
  we cant ship it in the release. Hope Yiqun and Da Zhang can make those
  changes quickly.
 
 
  Robin Anil | Software Engineer | +1 312 869 2602 | Google Inc.
 
 
  On Sun, Jun 23, 2013 at 8:46 PM, Grant Ingersoll gsing...@apache.org
 wrote:
 
  I see 1 issue left: MAHOUT-1214.  It is assigned to Robin.  Any chance
 we
  can finish this up this week?
 
  -Grant
 
  On Jun 23, 2013, at 9:26 AM, Suneel Marthi suneel_mar...@yahoo.com
  wrote:
 
   Finally got to finishing up M-833, the changes can be reviewed at
  https://reviews.apache.org/r/11774/diff/3/.
  
  
  
  
  
   
   From: Grant Ingersoll gsing...@apache.org
   To: dev@mahout.apache.org
   Sent: Tuesday, June 11, 2013 10:09 AM
   Subject: Re: 0.8 progress
  
  
   I pushed M-1030 and M-1233.  If we can get M-833 and M-1214 in by
  Thursday, I can roll an RC on Thursday.
  
   -Grant
  
   On Jun 11, 2013, at 8:56 AM, Grant Ingersoll gsing...@apache.org
  wrote:
  
   Down to 4 issues!  I would say what they are, but JIRA is flaking out
  again.
  
   My instinct is that 1030 and 1233 can be pushed.  Suneel has been
  working hard to get M-833 in.  Not sure on M-1214, Robin?
  
   -G
  
   On Jun 9, 2013, at 6:10 PM, Grant Ingersoll gsing...@apache.org
  wrote:
  
  
   On Jun 9, 2013, at 6:02 PM, Grant Ingersoll gsing...@apache.org
  wrote:
  
   M-1067 -- Dmitriy  --  This is an enhancement, should we push?
  
   Looks like this was committed already.
  
  
  
  
   
   Grant Ingersoll | @gsingers
   http://www.lucidworks.com
 
  
  Grant Ingersoll | @gsingers
  http://www.lucidworks.com
 
 
 
 
 
 
 

Re: Welcome new committers Gokhan Capan and Stevo Slavic

[Stevo Slavić]

Thanks Grant, Suneel and rest of the team,

I'm a Java software developer and OSS enthusiast from Serbia with 7 years
of professional experience in IT industry.
Together with teams I've been part of, I have designed, built and
successfully delivered multiple applications and websites from various
business domains (online media, e-government, telecommunications,
e-commerce). In both small and large enterprise scale apps, open source
technologies and communities around them were and remain to be one of the
key components and ingredients for success.

It's always a great pleasure for me to give back to OSS projects that I
use, through submitting patches or just being good community member.
So far I've contributed to and been involved the most on Spring framework
and other associated projects from the Spring portfolio.

Back in April last year I rediscovered my passion and interest in machine
learning, AI and computer science in general through prof. Andrew Ng's Coursera
machine learning MOOC https://www.coursera.org/course/ml which I successfully
completed http://bit.ly/sslavic-coursera-ml. Going from ML theory to
practice, through the mist of Big Data hype, lead me to the greatness of
Apache Mahout project.

You all do me great honor by accepting me into the team, team of
exceptional individuals yet great team players, with such positive and
creative atmosphere.
My contributions to the project so far were rather limited, and in near
future they are likely to remain so as I still have lots to learn first.
At least in the beginning, more than anything else I expect that I'll be
able to contribute to the project by making it even more approachable to
general audience of IT practitioners like myself through actively promoting
it, supporting users on the mailing list to my best, and working on the
documentation. Level of commitment will surely increase with time.

I thank you all once more for this wonderful opportunity, and wish us and
the project lots of success!

Kind regards,
Stevo Slavic.


On Tue, Jun 11, 2013 at 1:10 AM, Suneel Marthi suneel_mar...@yahoo.comwrote:

 Congrats Gokhan and Stevo!!




 
  From: Grant Ingersoll gsing...@apache.org
 To: dev@mahout.apache.org dev@mahout.apache.org
 Sent: Monday, June 10, 2013 5:04 PM
 Subject: Welcome new committers Gokhan Capan and Stevo Slavic


 Please join me in congratulating Mahout's newest committers, Gokhan Capan
 and Stevo Slavic, both of whom have been contributing to Mahout for some
 time now.

 Gokhan, Stevo, new committer tradition is to give a brief background on
 yourself, so you have the floor!

 Congrats,
 Grant

Re: Req: Configure Maven 3 in CI jobs, and enable distribution snapshot deploy

[Stevo Slavić]

+1 for enforcing Maven 3, it's more strict so will check and report issues
with build script, and newer versions of plugins require it or just work
and are tested with it.

Go to each job (e.g. https://builds.apache.org/job/mahout-nightly/ ), and
if you have access/rights click on Configure link; then in Build section,
there should be Maven Version drop-down, with hopefully some Maven 3
option in it. Click Save or Apply.
Check on the same page, if there are some prebuild/postbuild steps which
run maven, they also need to be configured to use Maven 3.

If nobody has appropriate access rights, maybe create support ticket on
INFRA.

Kind regards,
Stevo Slavić.


On Mon, May 27, 2013 at 12:34 PM, Sean Owen sro...@gmail.com wrote:

 (I snuck in this Maven requirement with some other updates to plugins. I
 think it is not strictly essential for the other plugins, so could be
 reverted. But Maven 3 has been out for nearly 3 years, and surely Apache
 itself should use it now. But I don't know how to configure these jobs to
 run with 3 vs 2.)


 On Mon, May 27, 2013 at 1:39 AM, Stevo Slavić ssla...@gmail.com wrote:

  Hello Apache Mahout developers,
 
  Several Apache Mahout build jobs are failing, they are configured to run
  with Apache Maven 2, while pom.xml has recently been changed to require
  Apache Maven 3. To fix this it's enough to update configuration of these
  jobs, so they use Apache Maven 3 to execute.
 
  While at it, please also configure mahout-nightly job to deploy/release
  distribution archive, by appending:
 
  -Dmahout.skip.distribution=false
 
  to the Maven goals of the job. I think this will be useful, Mahout
 beginner
  which wants to use latest algorithms, will not have to build Mahout
  herself, to get nicely packaged distribution of Apache Mahout from Apache
  snapshots repository like
 
 
 https://repository.apache.org/content/groups/snapshots/org/apache/mahout/mahout-distribution/0.8-SNAPSHOT/
 
  Current Maven goals for mahout-nightly job are clean install deploy.
 That
  install is redundant, it's implied because of deploy, both of these
  phases are in same, default lifecycle, executing up to deploy will run
  through install phase as well.
 
  Kind regards,
  Stevo Slavić.
 

Re: Req: Configure Maven 3 in CI jobs, and enable distribution snapshot deploy

[Stevo Slavić]

Nice I see builds are running, past Maven version check.

What do you all think about my second suggestion - to enable mahout-nightly
job to publish distribution archives on apache snapshots repository? One
more advantage of this would be to have publishing mechanism tested in at
least one CI build job.
To do this, one has to configure mahout-nightly job, append 
-Dmahout.skip.distribution=false to Maven build goals.


On Mon, May 27, 2013 at 7:50 PM, Ted Dunning ted.dunn...@gmail.com wrote:

 I changed all the Mahout projects I could find.

 I also deleted MahoutQM since it hadn't been run since 2010


 On Mon, May 27, 2013 at 5:21 AM, Sean Owen sro...@gmail.com wrote:

  That's a great description, thanks. I logged in to Jenkins, and I do not
  see a Configure link, so I likely do not have rights. I don't know who
  does?
 
 
  On Mon, May 27, 2013 at 12:41 PM, Stevo Slavić ssla...@gmail.com
 wrote:
 
   +1 for enforcing Maven 3, it's more strict so will check and report
  issues
   with build script, and newer versions of plugins require it or just
 work
   and are tested with it.
  
   Go to each job (e.g. https://builds.apache.org/job/mahout-nightly/ ),
  and
   if you have access/rights click on Configure link; then in Build
 section,
   there should be Maven Version drop-down, with hopefully some Maven 3
   option in it. Click Save or Apply.
   Check on the same page, if there are some prebuild/postbuild steps
 which
   run maven, they also need to be configured to use Maven 3.
  
   If nobody has appropriate access rights, maybe create support ticket on
   INFRA.
  
   Kind regards,
   Stevo Slavić.
  
  
   On Mon, May 27, 2013 at 12:34 PM, Sean Owen sro...@gmail.com wrote:
  
(I snuck in this Maven requirement with some other updates to
 plugins.
  I
think it is not strictly essential for the other plugins, so could be
reverted. But Maven 3 has been out for nearly 3 years, and surely
  Apache
itself should use it now. But I don't know how to configure these
 jobs
  to
run with 3 vs 2.)
   
   
On Mon, May 27, 2013 at 1:39 AM, Stevo Slavić ssla...@gmail.com
  wrote:
   
 Hello Apache Mahout developers,

 Several Apache Mahout build jobs are failing, they are configured
 to
   run
 with Apache Maven 2, while pom.xml has recently been changed to
  require
 Apache Maven 3. To fix this it's enough to update configuration of
   these
 jobs, so they use Apache Maven 3 to execute.

 While at it, please also configure mahout-nightly job to
  deploy/release
 distribution archive, by appending:

 -Dmahout.skip.distribution=false

 to the Maven goals of the job. I think this will be useful, Mahout
beginner
 which wants to use latest algorithms, will not have to build Mahout
 herself, to get nicely packaged distribution of Apache Mahout from
   Apache
 snapshots repository like


   
  
 
 https://repository.apache.org/content/groups/snapshots/org/apache/mahout/mahout-distribution/0.8-SNAPSHOT/

 Current Maven goals for mahout-nightly job are clean install
  deploy.
That
 install is redundant, it's implied because of deploy, both of
  these
 phases are in same, default lifecycle, executing up to deploy will
  run
 through install phase as well.

 Kind regards,
 Stevo Slavić.

   
  
 

Re: Req: Configure Maven 3 in CI jobs, and enable distribution snapshot deploy

[Stevo Slavić]

Binaries of individual Mahout modules are already being published by
mahout-nightly job to Apache snapshots repository, e.g. see
https://repository.apache.org/content/groups/snapshots/org/apache/mahout/mahout-core/0.8-SNAPSHOT/

To try Mahout 0.8-SNAPSHOT modules in an new or existing Mahout powered app
or service (even without distribution module published) one can define in
pom.xml a repository like:

...
repository
  idapache.snapshots/id
  urlhttps://repository.apache.org/content/groups/snapshots/url
  releasesenabledfalse/enabled/releases
  snapshots
enabledtrue/enabled
updatePolicydaily/updatePolicy
  /snapshots
/repository
...

then define Mahout modules dependency to version 0.8-SNAPSHOT and use them.


Once that switch is added to the Maven goals of mahout-nightly build job,
it will also publish Mahout distribution archives (zip, tar.gz, tar.bz2,
src and binaries bundles) to Apache snapshots repository at
https://repository.apache.org/content/groups/snapshots/org/apache/mahout/mahout-distribution/0.8-SNAPSHOT/

From there e.g. a MiA reader can download and unpack appropriate archive
(zip, tar.gz, or tar.bz2 binaries), configure MAHOUT_HOME environment
variable to point to unpacked directory and then run Mahout commands  try
examples.




On Mon, May 27, 2013 at 11:35 PM, Ted Dunning ted.dunn...@gmail.com wrote:

 This is a good idea to publish the snapshots.  It would definitely simplify
 bleeding edge projects.

 I have tried putting this onto the mahout-nightly job.

 What special pom invocation is required to consume these artifacts?


 On Mon, May 27, 2013 at 11:09 AM, Stevo Slavić ssla...@gmail.com wrote:

  Nice I see builds are running, past Maven version check.
 
  What do you all think about my second suggestion - to enable
 mahout-nightly
  job to publish distribution archives on apache snapshots repository? One
  more advantage of this would be to have publishing mechanism tested in at
  least one CI build job.
  To do this, one has to configure mahout-nightly job, append 
  -Dmahout.skip.distribution=false to Maven build goals.
 
 
  On Mon, May 27, 2013 at 7:50 PM, Ted Dunning ted.dunn...@gmail.com
  wrote:
 
   I changed all the Mahout projects I could find.
  
   I also deleted MahoutQM since it hadn't been run since 2010
  
  
   On Mon, May 27, 2013 at 5:21 AM, Sean Owen sro...@gmail.com wrote:
  
That's a great description, thanks. I logged in to Jenkins, and I do
  not
see a Configure link, so I likely do not have rights. I don't know
 who
does?
   
   
On Mon, May 27, 2013 at 12:41 PM, Stevo Slavić ssla...@gmail.com
   wrote:
   
 +1 for enforcing Maven 3, it's more strict so will check and report
issues
 with build script, and newer versions of plugins require it or just
   work
 and are tested with it.

 Go to each job (e.g. https://builds.apache.org/job/mahout-nightly/
 ),
and
 if you have access/rights click on Configure link; then in Build
   section,
 there should be Maven Version drop-down, with hopefully some
 Maven
  3
 option in it. Click Save or Apply.
 Check on the same page, if there are some prebuild/postbuild steps
   which
 run maven, they also need to be configured to use Maven 3.

 If nobody has appropriate access rights, maybe create support
 ticket
  on
 INFRA.

 Kind regards,
 Stevo Slavić.


 On Mon, May 27, 2013 at 12:34 PM, Sean Owen sro...@gmail.com
  wrote:

  (I snuck in this Maven requirement with some other updates to
   plugins.
I
  think it is not strictly essential for the other plugins, so
 could
  be
  reverted. But Maven 3 has been out for nearly 3 years, and surely
Apache
  itself should use it now. But I don't know how to configure these
   jobs
to
  run with 3 vs 2.)
 
 
  On Mon, May 27, 2013 at 1:39 AM, Stevo Slavić ssla...@gmail.com
 
wrote:
 
   Hello Apache Mahout developers,
  
   Several Apache Mahout build jobs are failing, they are
 configured
   to
 run
   with Apache Maven 2, while pom.xml has recently been changed to
require
   Apache Maven 3. To fix this it's enough to update configuration
  of
 these
   jobs, so they use Apache Maven 3 to execute.
  
   While at it, please also configure mahout-nightly job to
deploy/release
   distribution archive, by appending:
  
   -Dmahout.skip.distribution=false
  
   to the Maven goals of the job. I think this will be useful,
  Mahout
  beginner
   which wants to use latest algorithms, will not have to build
  Mahout
   herself, to get nicely packaged distribution of Apache Mahout
  from
 Apache
   snapshots repository like
  
  
 

   
  
 
 https://repository.apache.org/content/groups/snapshots/org/apache/mahout/mahout-distribution/0.8-SNAPSHOT/
  
   Current Maven goals for mahout-nightly job are clean install

Req: Configure Maven 3 in CI jobs, and enable distribution snapshot deploy

[Stevo Slavić]

Hello Apache Mahout developers,

Several Apache Mahout build jobs are failing, they are configured to run
with Apache Maven 2, while pom.xml has recently been changed to require
Apache Maven 3. To fix this it's enough to update configuration of these
jobs, so they use Apache Maven 3 to execute.

While at it, please also configure mahout-nightly job to deploy/release
distribution archive, by appending:

-Dmahout.skip.distribution=false

to the Maven goals of the job. I think this will be useful, Mahout beginner
which wants to use latest algorithms, will not have to build Mahout
herself, to get nicely packaged distribution of Apache Mahout from Apache
snapshots repository like
https://repository.apache.org/content/groups/snapshots/org/apache/mahout/mahout-distribution/0.8-SNAPSHOT/

Current Maven goals for mahout-nightly job are clean install deploy. That
install is redundant, it's implied because of deploy, both of these
phases are in same, default lifecycle, executing up to deploy will run
through install phase as well.

Kind regards,
Stevo Slavić.

Re: [jira] [Updated] (MAHOUT-1209) DRY out maven-compiler-plugin configuration

[Stevo Slavić]

I understand, thanks. This seems to be general ASF infra/policies and
GitHub pull requests issue.
Will continue to submit both pull requests on github and svn compatible
patches attached to JIRA, and close pull requests by myself once patches
get integrated/merged.

Kind regards,
Stevo Slavic.


On Sun, May 12, 2013 at 7:43 PM, Ted Dunning ted.dunn...@gmail.com wrote:



 We talked about this but it is difficult to switch the user base except at
 the beginning if a project.  For drill, as an example, we started with git.

 Unfortunately that still doesn't solve the pull problem since the apache
 source on GitHub is just a mirror and can't push updates back to apache.

 The only good news is that enough of use git that git formatted patches
 are ok.

 On May 12, 2013, at 2:05, Stevo Slavic (JIRA) j...@apache.org wrote:

  I wish Mahout used git as primary scm.

Re: Build failed in Jenkins: Mahout-Examples-Cluster-Reuters-II #478

[Stevo Slavić]

Some slave ran out of disk space?


Kind regards,
Stevo Slavic.


On Sun, May 12, 2013 at 9:16 PM, Apache Jenkins Server 
jenk...@builds.apache.org wrote:

 See 
 https://builds.apache.org/job/Mahout-Examples-Cluster-Reuters-II/478/changes
 

 Changes:

 [smarthi] Mahout-1207: DRY out maven-compiler-plugin configuration

 [smarthi] Mahout-1207: Fix typos in description in parent pom

 [smarthi] Mahout-1199: Improve javadoc comments of mahout-integration

 --
 [...truncated 2098 lines...]
 [INFO] Writing to
 /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/Mahout-Examples-Cluster-Reuters-II/trunk/math/target/generated-sources/mahout/org/apache/mahout/math/map/AbstractByteObjectMap.java
 [INFO] Writing to
 /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/Mahout-Examples-Cluster-Reuters-II/trunk/math/target/generated-sources/mahout/org/apache/mahout/math/map/AbstractCharObjectMap.java
 [INFO] Writing to
 /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/Mahout-Examples-Cluster-Reuters-II/trunk/math/target/generated-sources/mahout/org/apache/mahout/math/map/AbstractIntObjectMap.java
 [INFO] Writing to
 /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/Mahout-Examples-Cluster-Reuters-II/trunk/math/target/generated-sources/mahout/org/apache/mahout/math/map/AbstractShortObjectMap.java
 [INFO] Writing to
 /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/Mahout-Examples-Cluster-Reuters-II/trunk/math/target/generated-sources/mahout/org/apache/mahout/math/map/AbstractLongObjectMap.java
 [INFO] Writing to
 /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/Mahout-Examples-Cluster-Reuters-II/trunk/math/target/generated-sources/mahout/org/apache/mahout/math/map/AbstractFloatObjectMap.java
 [INFO] Writing to
 /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/Mahout-Examples-Cluster-Reuters-II/trunk/math/target/generated-sources/mahout/org/apache/mahout/math/map/AbstractDoubleObjectMap.java
 [INFO] Writing to
 /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/Mahout-Examples-Cluster-Reuters-II/trunk/math/target/generated-sources/mahout/org/apache/mahout/math/map/AbstractByteByteMap.java
 [INFO] Writing to
 /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/Mahout-Examples-Cluster-Reuters-II/trunk/math/target/generated-sources/mahout/org/apache/mahout/math/map/AbstractByteCharMap.java
 [INFO] Writing to
 /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/Mahout-Examples-Cluster-Reuters-II/trunk/math/target/generated-sources/mahout/org/apache/mahout/math/map/AbstractByteIntMap.java
 [INFO] Writing to
 /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/Mahout-Examples-Cluster-Reuters-II/trunk/math/target/generated-sources/mahout/org/apache/mahout/math/map/AbstractByteShortMap.java
 [INFO] Writing to
 /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/Mahout-Examples-Cluster-Reuters-II/trunk/math/target/generated-sources/mahout/org/apache/mahout/math/map/AbstractByteLongMap.java
 [INFO] Writing to
 /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/Mahout-Examples-Cluster-Reuters-II/trunk/math/target/generated-sources/mahout/org/apache/mahout/math/map/AbstractByteFloatMap.java
 [INFO] Writing to
 /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/Mahout-Examples-Cluster-Reuters-II/trunk/math/target/generated-sources/mahout/org/apache/mahout/math/map/AbstractByteDoubleMap.java
 [INFO] Writing to
 /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/Mahout-Examples-Cluster-Reuters-II/trunk/math/target/generated-sources/mahout/org/apache/mahout/math/map/AbstractCharByteMap.java
 [INFO] Writing to
 /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/Mahout-Examples-Cluster-Reuters-II/trunk/math/target/generated-sources/mahout/org/apache/mahout/math/map/AbstractCharCharMap.java
 [INFO] Writing to
 /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/Mahout-Examples-Cluster-Reuters-II/trunk/math/target/generated-sources/mahout/org/apache/mahout/math/map/AbstractCharIntMap.java
 [INFO] Writing to
 /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/Mahout-Examples-Cluster-Reuters-II/trunk/math/target/generated-sources/mahout/org/apache/mahout/math/map/AbstractCharShortMap.java
 [INFO] Writing to
 /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/Mahout-Examples-Cluster-Reuters-II/trunk/math/target/generated-sources/mahout/org/apache/mahout/math/map/AbstractCharLongMap.java
 [INFO] Writing to
 /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/Mahout-Examples-Cluster-Reuters-II/trunk/math/target/generated-sources/mahout/org/apache/mahout/math/map/AbstractCharFloatMap.java
 [INFO] Writing to
 

Re: [jira] [Updated] (MAHOUT-1209) DRY out maven-compiler-plugin configuration

[Stevo Slavić]

Organizations support isn't sufficient?

https://help.github.com/articles/what-s-the-difference-between-user-and-organization-accounts#organizations

I guess there's need for suborganizations for each apache project on
github. Not sure if that's supported or feasible with existing
organizations support.


On Sun, May 12, 2013 at 10:59 PM, Ted Dunning ted.dunn...@gmail.com wrote:

 The additional factor is that github doesn't provide sufficient control
 over access to individual projects.  If it were possible to ensure that
 only committers had access to the github mirror, it would be plausible to
 handle pull requests more directly, even with SVN as the primary repo.  We
 could handle the pull request using github and use git svn to push back to
 SVN.

 Until github does that (and there is no motion in that direction), then
 patches will rule.



 On Sun, May 12, 2013 at 1:50 PM, Stevo Slavić ssla...@gmail.com wrote:

  I understand, thanks. This seems to be general ASF infra/policies and
  GitHub pull requests issue.
  Will continue to submit both pull requests on github and svn compatible
  patches attached to JIRA, and close pull requests by myself once patches
  get integrated/merged.
 
  Kind regards,
  Stevo Slavic.
 
 
  On Sun, May 12, 2013 at 7:43 PM, Ted Dunning ted.dunn...@gmail.com
  wrote:
 
  
  
   We talked about this but it is difficult to switch the user base except
  at
   the beginning if a project.  For drill, as an example, we started with
  git.
  
   Unfortunately that still doesn't solve the pull problem since the
 apache
   source on GitHub is just a mirror and can't push updates back to
 apache.
  
   The only good news is that enough of use git that git formatted patches
   are ok.
  
   On May 12, 2013, at 2:05, Stevo Slavic (JIRA) j...@apache.org
 wrote:
  
I wish Mahout used git as primary scm.
  
 

Re: Call to action – Mahout needs your help

[Stevo Slavić]

Hello Mahout devs,

Please consider shipping Mahout 0.8 organized as it is now, and come back
to ideas for the future after release.

Personally, I'll consider Mahout only for problems that need to scale
horizontally, use a cluster, and use widely adopted platforms like Hadoop.
It's good to have library like Mahout focused to be container for just a
bunch of algorithms, and I'd like it to stay that way - fosters community
of other more specialized projects.

Btw, I agree wiki/docs needs to be improved. It would help to have better
definition of done - no undocumented commits/changes/new algorithms. Also,
Confluence powering wiki is outdated - doesn't Atlassian provide Apache
projects with free upgrades as well?
Because of infra issues, maybe better limit use of wiki and extend project
with reference documentation.

I agree, having more freely accessible data sets would help, not only
Mahout. Maybe create a subproject or separate Apache project for that.

As non-committer I'd contribute more to Mahout, had github be primary
source. Now, when I contribute a pull request, it gets merged to Apache git
server by committer, and I don't get recorded as contributor on github.
Maybe just workflow can be changed to improve this.

Discussing about ideas for the future, have Mahout committers considered
using scalding and/or algebird instead of or along with Java Hadoop API?

Kind regards,
Stevo Slavic.


On Mon, Mar 25, 2013 at 9:43 AM, Manuel Blechschmidt 
manuel.blechschm...@gmx.de wrote:

 Hello,

 On 25.03.2013, at 09:10, Sebastian Schelter wrote:

  Hi,
 
  throwing in my 2 cents here:
 
  I don't agree that we simply lack manpower but have a clear vision. I
  actually think its the other way round. I think Mahout is kind of stuck,
  because it does not have a clear vision.

 I fully agree. So I think Mahout needs a vision. The big problem about ML
 is that you can do everything with it but to make a difference you have to
 focus.

 I am using Mahout for solving business problems e.g.:

 - Online fraud
 - eCommerce recommendations
 - Demand forecasting

 One big piece that is missing for all the algorithms is a complete bundled
 data set that is solving a real business problem and with bundled I mean
 that it is in the Mahout source tree. If no real data is available
 generated data could be used.

 I tried to fill this gap for recommendations with my github project:

 https://github.com/ManuelB/facebook-recommender-demo

 This project seams to be  used by the community. You can get it, compile
 it and start it with 4 commands.

  ...
 
  It is also my personal experience (= I heard it over and over again from
  our users) that it is extremely hard to get started with Mahout using
  the available documentation. MiA is the exception to this, but people
  have to buy it first and it lacks a lot of the latest developments. It
  would be awesome to have a reworked wiki that is qualitatively
  comparable to MiA.

 So this is the nature of a framework. If you really want people to get
 started easily you have to provide a full blown example where you can just
 replace the example data with your data.

 I don't think that enough manpower can be acquired to create a visual GUI
 for Mahout. Further I don't think that this would help. There are already
 excellent GUIs for ML e.g. Weka (http://www.cs.waikato.ac.nz/ml/weka/)
 and RStudio (http://www.rstudio.com/)


 
  Best,
  Sebastian

 Hope this helps
 Manuel

 
  On 25.03.2013 07:29, Isabel Drost-Fromm wrote:
 
 
  On Monday, March 25, 2013 07:22:46 AM Isabel Drost-Fromm wrote:
  On Sunday, March 24, 2013 05:38:00 PM Grant Ingersoll wrote:
  On Mar 24, 2013, at 5:03 PM, Isabel Drost-Fromm wrote:
  What about an experiment: If you (reading this mail) were to write a
 two
  sentence vision statement for Mahout as you see it - what would that
 be?
 
  Produce open source, scalable machine learning code using a community
  development model.
 
  So taking that apart:
 
  - Hadoop is not necessarily part of the equation. All that we promise
 are
  implemenations that are reasonably scalable.
 
  - We play well with small-ish (fits in memory) and large (fits only in
 memory of
  many machines) or huge (fits only on disk) datasets.
 
  - There is no restriction in there wrt. supporting only specific use
 cases -
  in particular no restriction to be recommendations only.
 
  - There is no restriction to only batch or only online learning.
 
  If we want to be that broad we definitely lack lots of people, I think.
 
  The other question that I cannot answer today: Do we want to be a Java
  Library that people link with their project, a standalone program that
  people interact with via the command line, a basis that people can
 easily
  integrate into their
 Pig/Hive/Cascalog/Scalding/Cascading/what-ever-else
  workflows or all of these?
 
 
 

 --
 Manuel Blechschmidt
 M.Sc. IT Systems Engineering
 Dortustr. 57
 14467 Potsdam
 Mobil: 0173/6322621
 Twitter: 

Re: Call to action – Mahout needs your help

[Stevo Slavić]

Thanks for heads up!

I meant maybe to re-implement Mahout java Hadoop code to use scalding, and
algebird. For me it would be great way to learn all of these technologies
(scala, mahout, hadoop, cascading, scalding, algebird). Expected/desired
improvement for Mahout committers and users would be hopefully less code in
Mahout projec itselft, easier to maintain and learn, existing and implement
new algorithms.

Kind regards,
Stevo Slavic.


On Mon, Mar 25, 2013 at 1:08 PM, Isabel Drost isa...@apache.org wrote:

 Hi,

 On Mon, Mar 25, 2013 at 11:15 AM, Stevo Slavić ssla...@gmail.com wrote:

  Please consider shipping Mahout 0.8 organized as it is now, and come back
  to ideas for the future after release.
 

 Personally I see the current discussion as a means to find out what people
 want Mahout to be in the long time and on how to come back to increased
 activity.



 
  I agree, having more freely accessible data sets would help, not only
  Mahout. Maybe create a subproject or separate Apache project for that.
 

 There is one already: http://lucene.apache.org/openrelevance/ - though
 currently there's not too much activity.



 
  As non-committer I'd contribute more to Mahout, had github be primary
  source. Now, when I contribute a pull request, it gets merged to Apache
 git
  server by committer, and I don't get recorded as contributor on github.
  Maybe just workflow can be changed to improve this.
 

 Valuable input indeed. Though given that we are still using svn as
 canonical version control system that sounds like a bigger project to me.


 
  Discussing about ideas for the future, have Mahout committers considered
  using scalding and/or algebird instead of or along with Java Hadoop API?
 
 
 Just to  clarify: Do you mean re-implenting what is available in these
 languages or making what is implemented available to these languages?


 Isabel