Re: [VOTE] Apache SystemML 0.10.0-incubating (RC1)

Hi Luciano, 10 of the 11 artifacts look good to me for LICENSE and NOTICE (as far as I can tell they reflect the artifact contents). However the standalone uberjar (systemml-0.10.0-incubating-standalone.jar) does not have the correct LICENSE and NOTICE (one of my commits in the last week must

Re: [VOTE] Apache SystemML 0.10.0-incubating (RC1)

I may have found an issue with the standalone (uber) jar LICENSE and NOTICE. Investigating. Deron On Wed, May 25, 2016 at 12:47 PM, wrote: > +1 > > I ran scripts in Jupyter and Zeppelin using both the Scala and Python > MLContext APIs in order to test our notebook

Re: Location for release validation checklist?

Hi Luciano, A very basic checklist has been created at https://issues.apache.org/jira/browse/SYSTEMML-708 Thanks, Deron On Wed, May 25, 2016 at 11:54 AM, Luciano Resende wrote: > Great, so, once you push your document, I will update with the build > release portion. > >

Re: missing release candidate checksums?

Thanks, they should all be on the staging site now. On Wed, May 25, 2016 at 11:10 AM, Deron Eriksson wrote: > and maybe: > ? systemml-0.10.0-incubating.pom.md5 > > Also, the previous release had sha1 checksums. Do we need those too or is > that overkill? > > Deron > > >

Re: Discussion on GPU backend

Luciano: Yes, there was a bit of confusion and hence wanted to iron things out to foster collaboration and community feedback on GPU backend. There are multiple issues: 1. Any work on smaller GPU PRs is dependent on the initial PR getting into the master (as the initial PR contains the

Re: missing release candidate checksums?

and maybe: ? systemml-0.10.0-incubating.pom.md5 Also, the previous release had sha1 checksums. Do we need those too or is that overkill? Deron On Wed, May 25, 2016 at 10:16 AM, Luciano Resende wrote: > On Tue, May 24, 2016 at 5:20 PM, Deron Eriksson

Re: Discussion on GPU backend

In my opinion, the problem with using a separate branch with longer-term work, rather than smaller PRs into the master, is that after several commits, say 10 or 20, it becomes much more difficult to rebase without running into nasty merge conflicts, especially when those conflicts are on an

Re: Discussion on GPU backend

Yeah to do this in the most "Apache Way (TM)", as well as to maintain sanity, we should definitely use JIRA issues (ideally actual "sub tasks") and PRs to split up major features. It would also be great to split it up into chunks of varying complexity that do not block others, so that we could

Re: Discussion on GPU backend

On Wed, May 25, 2016 at 6:03 AM, Berthold Reinwald wrote: > the discussion is less about (1), (2), or (3). As practiced so far, (3) is > the way to go. > > The question is about (A) or (B). Curious was the Apache suggested > practice is. > > Apache is key on fostering open