Re: 3rdparty packages as submodules

[Stephen Bull]

I like 3rdparty, and definitely helps newcomers too. As long as it's kept
relatively clean and up-to-date of course (not sure if that's a case for or
against however!). :)

On Mon, 20 Nov 2017 at 19:25 Chris Olivier  wrote:

> I support putting gtest in 3rdparty as well. That being said, which of
> these should we be storing in the Apache repository and which do we pull
> from their source repositories. What’s standard practice in this case for
> Apache projects?
>
> On Mon, Nov 20, 2017 at 5:54 PM Pedro Larroy  >
> wrote:
>
> > We could also add gtest as well for example.
> >
> >
> >
> > I would like to point out that is quite cumbersome to get your code
> > tested and ready before sending a PR, this includes installing
> > cpplint, pylint, gtest…
> >
> > Installing gtest and bootstrapping it is not completely trivial.
> >
> >
> >
> > Kind regards.
> >
> > On Mon, Nov 20, 2017 at 11:23 AM, Eric Xie  wrote:
> > > I'm fine with a 3rdparty folder. Not sure about apache legal.
> > >
> > > On 2017-11-17 10:25, Chris Olivier  wrote:
> > >> All,
> > >>
> > >> I often find it desirable to have a method for 3rdparty packages to be
> > >> included (possibly optionally) in a 3rdparty directory.   We do this
> > with
> > >> 'cub' to some degree, but it's in the root and is actually a fork in
> the
> > >> dmlc repository.  Some samples of what might go in there:
> > >>
> > >> 1) Intel OpenMP (llvm-openmp) -- In order to use Intel OMP by default
> > >> 2) gperftools -- In order to build statically with -fPIC, which isn't
> > the
> > >> case with the general distribution
> > >> 3) mkl-dnn -- In order to build and have debug information available
> for
> > >> mkl-dnn (and possibly submit bugfixes)
> > >>
> > >> What do you all think?
> > >>
> > >> -Chris
> > >>
> >
>

Re: [DISCUSSION] Adding labels to PRs

[Stephen Bull]

As a complete noob here and someone without a JIRA account, it seems I can
at least view JIRA issues (so a plus for regular users when it comes to
release notes). And when it comes time to start contributing, I don't see
having to create a JIRA account to be a big deal, especially if the
associated overhead between JIRA and PRs is fairly minimal. It seems there
are many benefits given the replies so far.

Cheers,
Stephen

On Mon, 13 Nov 2017 at 11:28 Bhavin Thaker  wrote:

> +1 for better [1] PR Titles. As suggested by Madan and use by Spark, the
> current PR template seems to be ignored by folks and so we may want to
> simplify it to:
>
> Q1. What changes were proposed in this pull request?
>
> Q2. How was this patch tested?
>
>
> +1 to either [2] Jira OR [3] PR labels.
>
> Bhavin Thaker.
>
> On Fri, Nov 10, 2017 at 10:40 AM, Markus Weimer  wrote:
>
> > Option 2 works for us over in REEF. We are a bit (too) religious about it
> > [0], but it creates really nice commit messages[1].
> >
> > We require each commit message to start with a one line summary which
> names
> > the JIRA in brackets and describes the change, e.g. `[REEF-1234] Added
> > integration with mxnet`. The remainder of the commit message is valid
> > markdown, and they all end in a block which contains explicit references
> to
> > the JIRA and pull request:
> >
> > ```
> > JIRA:
> >   [REEF-1234](https://issues.apache.org/jira/browse/REEF-1234)
> >
> > Pull Request:
> >   This closes #1234
> > ```
> >
> > The hope is that this structure will eventually proof useful in automated
> > analysis. Then again, we haven't done that ever :)
> >
> > Markus
> >
> > [0]: https://cwiki.apache.org/confluence/display/REEF/Commit+Messages
> > [1]: https://github.com/apache/reef/commits/master
> >
>

Request for invitation to MXNet Slack channel

[Stephen Bull]

Hi,

I'm a senior software engineer just now beginning to work on my own AI/ML
project. I had been researching various ML frameworks for my needs and
MXNet seemed to be a good fit for me (technically, for its flexibility, and
also from an open source standpoint), I'm hoping I can contribute to the
project in the future when I start developing proper with MXNet.

I recently subscribed to the MXNet Apache mailing list and I've begun going
through the tutorials (currently for Python). While going through tutorial
docs and code I have noticed a few typos here and there, both within the
online docs and also with debug/error messages coming out of the MXNet
library. I'd like to start contributing to the codebase in the future, and
as I come across small issues like these I feel like maybe this would be a
good place to start.

So with that said, I'm emailing to request an invitation to the MXNet Slack
channel! :)

Thanks,
Stephen