Dear podling,
This email was sent by an automated system on behalf of the Apache
Incubator PMC. It is an initial reminder to give you plenty of time to
prepare your quarterly board report.
The board meeting is scheduled for Wed, 15 June 2016, 10:30 am PDT.
The report for your podling will form a
That sounds good to me.
On Wed, May 25, 2016 at 3:58 PM, Luciano Resende
wrote:
> On Wed, May 25, 2016 at 1:54 PM, Deron Eriksson
> wrote:
>
> > 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). Ho
Great, I created SYSTEMML-710 to track this. Would be good as a simple starter
task as well.
--
Mike Dusenberry
GitHub: github.com/dusenberrymw
LinkedIn: linkedin.com/in/mikedusenberry
Sent from my iPhone.
> On May 25, 2016, at 1:16 PM, Luciano Resende wrote:
>
>> On Wed, May 25, 2016 at 1
Yeah let's just remove that specific standalone JAR. It was only added to the
Pom file for local testing, and not really intended for final release, so no
worries. We still have the standalone zip/tar releases as well.
--
Mike Dusenberry
GitHub: github.com/dusenberrymw
LinkedIn: linkedin.com/in
On Wed, May 25, 2016 at 1:54 PM, Deron Eriksson
wrote:
> 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
> corr
Off course, my +1 as well.
On Fri, May 20, 2016 at 10:45 PM, Luciano Resende
wrote:
> Please vote on releasing the following candidate as Apache SystemML
> version 0.10.0-incubating !
>
> The vote is open for at least 72 hours and will close on Saturday,
> Wednesday 25 and passes if a majority o
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 have
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 integration.
>
> One thing to
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 integration.
>
> One thing to note is that our Python API file, `SystemML.py`, is not
> included with the main distribution. We ca
+1
I ran scripts in Jupyter and Zeppelin using both the Scala and Python MLContext
APIs in order to test our notebook integration.
One thing to note is that our Python API file, `SystemML.py`, is not included
with the main distribution. We can work around this, and it should not block
this re
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.
>
> On Wed, May 25, 2016 a
Hi,
I created a release checklist JIRA for the release candidate.
https://issues.apache.org/jira/browse/SYSTEMML-708
Please feel free to add items, remove items, modify items, or post
validation results.
Thanks!
Deron
Great, so, once you push your document, I will update with the build
release portion.
On Wed, May 25, 2016 at 11:03 AM, Deron Eriksson
wrote:
> Hi,
>
> Checklist on a jira sounds good to me. Sorry if I misunderstood the
> previous comment.
>
> Deron
>
>
> On Wed, May 25, 2016 at 10:07 AM, Lucian
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
>
>
> On Wed, May 25, 2016 at 1
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 buffer-poo
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
> wrote:
>
> > Hi,
> >
> > I noticed that
Hi,
Checklist on a jira sounds good to me. Sorry if I misunderstood the
previous comment.
Deron
On Wed, May 25, 2016 at 10:07 AM, Luciano Resende
wrote:
> On Wed, May 25, 2016 at 9:06 AM, wrote:
>
> > Another possibility would be to create a new JIRA issue for each release
> > (candidate) an
On Tue, May 24, 2016 at 5:20 PM, Deron Eriksson
wrote:
> Hi,
>
> I noticed that not all the artifacts at
>
> https://dist.apache.org/repos/dist/dev/incubator/systemml/0.10.0-incubating-rc1/
> have md5 checksums.
>
> Also, the previous release (see
>
> https://repo1.maven.org/maven2/org/apache/sys
On Wed, May 25, 2016 at 9:06 AM, wrote:
> Another possibility would be to create a new JIRA issue for each release
> (candidate) and track what had been tested there. If we do that, then we
> could include just the generic instructions in a markdown file in our repo.
>
>
Yes, this was my suggesti
But, from the original question, I was under the impression that creating
and merging multiple small prs were not a possible direction. If that is
ok, then it's regular development practice.
On Wed, May 25, 2016 at 9:20 AM, wrote:
> In my opinion, the problem with using a separate branch with lo
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 inte
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 g
Another possibility would be to create a new JIRA issue for each release
(candidate) and track what had been tested there. If we do that, then we could
include just the generic instructions in a markdown file in our repo.
--
Mike Dusenberry
GitHub: github.com/dusenberrymw
LinkedIn: linkedin.co
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 collaboration, so speci
Thanks Berthold and Matthias for your suggestions. It is important to note
whether we go with (A) or (B), the initial PR will be squashed in one
commit and individual commits by external contributor will be lost in the
process. However, since we are planning to go with option (3), the impact
won't
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.
Regards,
Berthold Reinwald
IBM Almaden Research Center
office: (408) 927 2208; T/L: 457 2208
e-mail: reinw...@us.ibm.com
F
26 matches
Mail list logo
