Re: [VOTE] Release MXNet version 1.2.1.RC1

[Haibin Lin]

+1
Built from source with cuda and dist kvstore. Ran dist_sync_kvstore.py
nightly test and it passed.

Best,
Haibin

On Wed, Jul 11, 2018 at 6:13 PM, Roshani Nagmote 
wrote:

> Hi All,
>
> Could you please test and vote for this release? Voting will end tomorrow
> by 5:50 pm PDT.
>
> Thanks,
> Roshani
>
> On Mon, Jul 9, 2018 at 4:53 PM Roshani Nagmote 
> wrote:
>
> > Hi all,
> >
> > I would like to propose a vote to release Apache MXNet (incubating)
> > version
> > 1.2.1.RC1. Voting will start now (Monday, Jul 9th) and end at 5:50 PM
> > PDT, Thursday, July 12th.
> >
> > Link to release candidate 1.2.1.rc1:
> > *https://github.com/apache/incubator-mxnet/releases/tag/1.2.1.rc1
> > *
> >
> > View this page, click on "Build from Source", and use the source code
> > obtained from 1.2.1.rc1 tag:
> > https://mxnet.incubator.apache.org/install/index.html
> >
> > (Note: The README.md points to the 1.2.1 tag and does not work at the
> > moment.)
> >
> > Please remember to test first before voting accordingly:
> >
> > +1 = approve
> > +0 = no opinion
> > -1 = disapprove (provide reason)
> >
> > Thanks,
> > Roshani
> >
>

Squash/Merge PRs

[Naveen Swamy]

Hi All,

I am seeing that maintainers merge PRs into the repo, they are squashing
the commits in the PR, which I understand and agree is to keep a sane
commit history, however this is causing problem when there are multiple
contributors involved on a PR(by contributing to a fork of the repo) this
effectively removes credit for multiple contributors involved and shows all
code as authored by the contributor who created the PR.

Can I request maintainers to not squash PRs if there are multiple
contributors involved on the PR.

Also on the same note, I request contributors(regardless of multiple
contributors or not) to keep a clean commit history by squashing the
commits and not push all your WIP commits to the PR. this will help us keep
our commit history clean and meaningful.

Let me know your thoughts/better approach or If I have misunderstood how
this works.

Thanks, Naveen

Re: C++ api issue labeling

[Haibin Lin]

+1 merging "feature" with "feature request"

On Tue, Jul 10, 2018 at 12:59 PM, Anirudh Acharya 
wrote:

> There is another instance of label duplication - We have labels "Feature" (
> https://github.com/apache/incubator-mxnet/labels/Feature ) and "Feature
> Request" (
> https://github.com/apache/incubator-mxnet/labels/Feature%20request ). I
> don't think there is much difference between these two labels.
>
> It would make sense to merge the "Feature" label into "Feature Request".
>
>
> Thanks
> Anirudh
>
>
> On Wed, Jun 27, 2018 at 3:50 PM Hagay Lupesko  wrote:
>
> > Thank you everyone for your suggestions.
> > I will work with a committer to get this updated ASAP.
> >
> > On Mon, Jun 25, 2018 at 8:55 AM Marco de Abreu
> >  wrote:
> >
> > > +1 to renaming to Backend
> > >
> > > On Mon, Jun 25, 2018 at 10:13 AM Hagay Lupesko 
> > wrote:
> > >
> > > > Thanks Lin for your feedback.
> > > > Bumping again to get more feedback before concluding.
> > > >
> > > > On Fri, Jun 22, 2018 at 8:53 AM Lin Yuan 
> wrote:
> > > >
> > > > > I agree with Hagay. Using "Backend" as label makes it much easier
> to
> > > > track.
> > > > >  "C++" label only describes the language used in implementation,
> > > > "Backend"
> > > > > better describes the nature of the work (let's assume we change the
> > > > backend
> > > > > implementation from C++ to other languages in the future).
> > > > >
> > > > > Lin
> > > > >
> > > > > On Fri, Jun 22, 2018 at 1:09 AM Hagay Lupesko 
> > > wrote:
> > > > >
> > > > > > Thanks everyone for chiming in and clarifying.
> > > > > > It seems that the "C++" label name is confusing for our community
> > > since
> > > > > it
> > > > > > can be interpreted as both the CPP API and the backend...
> > > > > > As an anecdote, this issue [1
> > > > > > ] is
> > labeled
> > > > as
> > > > > > "C++" but is about the CPP API, not the backend.
> > > > > >
> > > > > > Should we just rename "C++" to "Backend" to avoid confusion?
> > > > > >
> > > > > > [1] https://github.com/apache/incubator-mxnet/issues/10937
> > > > > >
> > > > > > On Thu, Jun 21, 2018 at 12:39 PM Pedro Larroy <
> > > > > > pedro.larroy.li...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Agree with Anirudh, they are different things. Maybe change the
> > > "C++"
> > > > > > label
> > > > > > > to "backend" would be more informative?
> > > > > > >
> > > > > > > On Thu, Jun 21, 2018 at 12:11 PM Anirudh <
> anirudh2...@gmail.com>
> > > > > wrote:
> > > > > > >
> > > > > > > > Hi Hagay,
> > > > > > > >
> > > > > > > > I think we should keep these two labels seperate since they
> > mean
> > > > > > > different
> > > > > > > > things.
> > > > > > > > The C++ label refers to the issue for MXNet backend and the
> CPP
> > > > > package
> > > > > > > > refers to the CPP language binding for mxnet.
> > > > > > > > We can still make C++ API great again irrespective by
> filtering
> > > out
> > > > > CPP
> > > > > > > > package issues :).
> > > > > > > >
> > > > > > > > Anirudh
> > > > > > > >
> > > > > > > >
> > > > > > > > On Thu, Jun 21, 2018 at 11:56 AM, Hagay Lupesko <
> > > lupe...@gmail.com
> > > > >
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Hey community,
> > > > > > > > >
> > > > > > > > > I was going over the open GitHub issues for MXNet, and
> > noticed
> > > > that
> > > > > > we
> > > > > > > > have
> > > > > > > > > two labels for the CPP API: "CPP package", "C++"
> > > > > > > > >
> > > > > > > > > Wanted to suggest we remove "CPP package" and just stick to
> > > "C++"
> > > > > > > > > This will make it easier for the community to classify
> issues
> > > and
> > > > > > focus
> > > > > > > > on
> > > > > > > > > making the C++ API great again ;)
> > > > > > > > >
> > > > > > > > > Let me know if someone has any concerns, otherwise I will
> > find
> > > a
> > > > > > > > committer
> > > > > > > > > that I can work with to make this change.
> > > > > > > > >
> > > > > > > > > Thanks!
> > > > > > > > > Hagay
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Squash/Merge PRs

[Marco de Abreu]

Hi Naveen,

I'm in favour of the squashing, considering the number of commits in some
PRs and especially because of some people making commit messages a la "fix"
"fix" "fix" all the time. Additionally, it gets hard (not impossible, just
more inconvenient) to determine the atomic states of master - aka, which
commits are separate from each other. You should consider that intermediary
commits are unstable (fail CI) and thus it could be very hard to bisect
failures in future - and the commit history gets cluttered.

As alternative, I'd like to suggest the co-author field for these cases.
Further documentation is available at
https://blog.github.com/2018-01-29-commit-together-with-co-authors/.

I definitely agree with the second part. We should all lead by example and
maintain a high quality by keeping our commit messages clean and
meaningful. When I receive an email notification that a new commit has been
added and it only contains "fix" as title, it's not that helpful and also
it's hard to track the development of a PR overtime. E.g., why has
something been changed? Was there maybe a bug that we didn't cover with
tests but the author just hacked something to get it to work but the
problem still lays somewhere? We won't know that way and it makes it harder
for us to review.

Best regards,
Marco


Naveen Swamy  schrieb am Do., 12. Juli 2018, 10:09:

> Hi All,
>
> I am seeing that maintainers merge PRs into the repo, they are squashing
> the commits in the PR, which I understand and agree is to keep a sane
> commit history, however this is causing problem when there are multiple
> contributors involved on a PR(by contributing to a fork of the repo) this
> effectively removes credit for multiple contributors involved and shows all
> code as authored by the contributor who created the PR.
>
> Can I request maintainers to not squash PRs if there are multiple
> contributors involved on the PR.
>
> Also on the same note, I request contributors(regardless of multiple
> contributors or not) to keep a clean commit history by squashing the
> commits and not push all your WIP commits to the PR. this will help us keep
> our commit history clean and meaningful.
>
> Let me know your thoughts/better approach or If I have misunderstood how
> this works.
>
> Thanks, Naveen
>

Re: C++ api issue labeling

[Marco de Abreu]

+1 to combining feature and feature request

Haibin Lin  schrieb am Do., 12. Juli 2018, 10:15:

> +1 merging "feature" with "feature request"
>
> On Tue, Jul 10, 2018 at 12:59 PM, Anirudh Acharya 
> wrote:
>
> > There is another instance of label duplication - We have labels
> "Feature" (
> > https://github.com/apache/incubator-mxnet/labels/Feature ) and "Feature
> > Request" (
> > https://github.com/apache/incubator-mxnet/labels/Feature%20request ). I
> > don't think there is much difference between these two labels.
> >
> > It would make sense to merge the "Feature" label into "Feature Request".
> >
> >
> > Thanks
> > Anirudh
> >
> >
> > On Wed, Jun 27, 2018 at 3:50 PM Hagay Lupesko  wrote:
> >
> > > Thank you everyone for your suggestions.
> > > I will work with a committer to get this updated ASAP.
> > >
> > > On Mon, Jun 25, 2018 at 8:55 AM Marco de Abreu
> > >  wrote:
> > >
> > > > +1 to renaming to Backend
> > > >
> > > > On Mon, Jun 25, 2018 at 10:13 AM Hagay Lupesko 
> > > wrote:
> > > >
> > > > > Thanks Lin for your feedback.
> > > > > Bumping again to get more feedback before concluding.
> > > > >
> > > > > On Fri, Jun 22, 2018 at 8:53 AM Lin Yuan 
> > wrote:
> > > > >
> > > > > > I agree with Hagay. Using "Backend" as label makes it much easier
> > to
> > > > > track.
> > > > > >  "C++" label only describes the language used in implementation,
> > > > > "Backend"
> > > > > > better describes the nature of the work (let's assume we change
> the
> > > > > backend
> > > > > > implementation from C++ to other languages in the future).
> > > > > >
> > > > > > Lin
> > > > > >
> > > > > > On Fri, Jun 22, 2018 at 1:09 AM Hagay Lupesko  >
> > > > wrote:
> > > > > >
> > > > > > > Thanks everyone for chiming in and clarifying.
> > > > > > > It seems that the "C++" label name is confusing for our
> community
> > > > since
> > > > > > it
> > > > > > > can be interpreted as both the CPP API and the backend...
> > > > > > > As an anecdote, this issue [1
> > > > > > > ] is
> > > labeled
> > > > > as
> > > > > > > "C++" but is about the CPP API, not the backend.
> > > > > > >
> > > > > > > Should we just rename "C++" to "Backend" to avoid confusion?
> > > > > > >
> > > > > > > [1] https://github.com/apache/incubator-mxnet/issues/10937
> > > > > > >
> > > > > > > On Thu, Jun 21, 2018 at 12:39 PM Pedro Larroy <
> > > > > > > pedro.larroy.li...@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Agree with Anirudh, they are different things. Maybe change
> the
> > > > "C++"
> > > > > > > label
> > > > > > > > to "backend" would be more informative?
> > > > > > > >
> > > > > > > > On Thu, Jun 21, 2018 at 12:11 PM Anirudh <
> > anirudh2...@gmail.com>
> > > > > > wrote:
> > > > > > > >
> > > > > > > > > Hi Hagay,
> > > > > > > > >
> > > > > > > > > I think we should keep these two labels seperate since they
> > > mean
> > > > > > > > different
> > > > > > > > > things.
> > > > > > > > > The C++ label refers to the issue for MXNet backend and the
> > CPP
> > > > > > package
> > > > > > > > > refers to the CPP language binding for mxnet.
> > > > > > > > > We can still make C++ API great again irrespective by
> > filtering
> > > > out
> > > > > > CPP
> > > > > > > > > package issues :).
> > > > > > > > >
> > > > > > > > > Anirudh
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Thu, Jun 21, 2018 at 11:56 AM, Hagay Lupesko <
> > > > lupe...@gmail.com
> > > > > >
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Hey community,
> > > > > > > > > >
> > > > > > > > > > I was going over the open GitHub issues for MXNet, and
> > > noticed
> > > > > that
> > > > > > > we
> > > > > > > > > have
> > > > > > > > > > two labels for the CPP API: "CPP package", "C++"
> > > > > > > > > >
> > > > > > > > > > Wanted to suggest we remove "CPP package" and just stick
> to
> > > > "C++"
> > > > > > > > > > This will make it easier for the community to classify
> > issues
> > > > and
> > > > > > > focus
> > > > > > > > > on
> > > > > > > > > > making the C++ API great again ;)
> > > > > > > > > >
> > > > > > > > > > Let me know if someone has any concerns, otherwise I will
> > > find
> > > > a
> > > > > > > > > committer
> > > > > > > > > > that I can work with to make this change.
> > > > > > > > > >
> > > > > > > > > > Thanks!
> > > > > > > > > > Hagay
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Squash/Merge PRs

[Hao Jin]

+1 for Marco's proposal on using the co-author field. IMHO the usage of
co-author field should not be that often, consider:
1) If a PR is so big that it needs multiple people to contribute a
substantial part of it, why can't that PR be broken down into smaller PRs
each submitted by single one of them?
2) If a PR is small enough (for example, < 300 lines), why can't a single
person complete it?
3) If a majority of PR is done by someone, and there's some minor issue
he/she needs help with(a small bug, incomplete doc), why can't that be done
through code reviews?
>From the above 3 situations we can see that collaborations on individual
PRs should not be quite often, but I do agree that it could still be
necessary when someone lacks the related expertise/knowledge on some
necessary part of that PR given that the required knowledge cannot be
picked up in a short period of time.

I do agree that keeping the commit histories of PRs clean is very important
as it could be confusing when reviewing PRs, but that really depends on
personal preferences (For my case, I usually do "git commit --amend" on
trivial changes and get a new commit for bigger changes such as a
checkpoint of my whole PR). With growing the community and attracting more
contributors as a high priority for our project, I would prefer that we do
not put even more burden on the contributors by asking them to manage and
squash the commits themselves just for the not-so-often cases of having
multiple contributors on a single PR.
Best regards,
Hao

On Thu, Jul 12, 2018 at 12:35 AM, Marco de Abreu <
marco.g.ab...@googlemail.com.invalid> wrote:

> Hi Naveen,
>
> I'm in favour of the squashing, considering the number of commits in some
> PRs and especially because of some people making commit messages a la "fix"
> "fix" "fix" all the time. Additionally, it gets hard (not impossible, just
> more inconvenient) to determine the atomic states of master - aka, which
> commits are separate from each other. You should consider that intermediary
> commits are unstable (fail CI) and thus it could be very hard to bisect
> failures in future - and the commit history gets cluttered.
>
> As alternative, I'd like to suggest the co-author field for these cases.
> Further documentation is available at
> https://blog.github.com/2018-01-29-commit-together-with-co-authors/.
>
> I definitely agree with the second part. We should all lead by example and
> maintain a high quality by keeping our commit messages clean and
> meaningful. When I receive an email notification that a new commit has been
> added and it only contains "fix" as title, it's not that helpful and also
> it's hard to track the development of a PR overtime. E.g., why has
> something been changed? Was there maybe a bug that we didn't cover with
> tests but the author just hacked something to get it to work but the
> problem still lays somewhere? We won't know that way and it makes it harder
> for us to review.
>
> Best regards,
> Marco
>
>
> Naveen Swamy  schrieb am Do., 12. Juli 2018, 10:09:
>
> > Hi All,
> >
> > I am seeing that maintainers merge PRs into the repo, they are squashing
> > the commits in the PR, which I understand and agree is to keep a sane
> > commit history, however this is causing problem when there are multiple
> > contributors involved on a PR(by contributing to a fork of the repo) this
> > effectively removes credit for multiple contributors involved and shows
> all
> > code as authored by the contributor who created the PR.
> >
> > Can I request maintainers to not squash PRs if there are multiple
> > contributors involved on the PR.
> >
> > Also on the same note, I request contributors(regardless of multiple
> > contributors or not) to keep a clean commit history by squashing the
> > commits and not push all your WIP commits to the PR. this will help us
> keep
> > our commit history clean and meaningful.
> >
> > Let me know your thoughts/better approach or If I have misunderstood how
> > this works.
> >
> > Thanks, Naveen
> >
>

Re: C++ api issue labeling

[Hagay Lupesko]

+1 to combining feature and feature request

On Thu, Jul 12, 2018 at 12:37 AM Marco de Abreu
 wrote:

> +1 to combining feature and feature request
>
> Haibin Lin  schrieb am Do., 12. Juli 2018,
> 10:15:
>
> > +1 merging "feature" with "feature request"
> >
> > On Tue, Jul 10, 2018 at 12:59 PM, Anirudh Acharya  >
> > wrote:
> >
> > > There is another instance of label duplication - We have labels
> > "Feature" (
> > > https://github.com/apache/incubator-mxnet/labels/Feature ) and
> "Feature
> > > Request" (
> > > https://github.com/apache/incubator-mxnet/labels/Feature%20request ).
> I
> > > don't think there is much difference between these two labels.
> > >
> > > It would make sense to merge the "Feature" label into "Feature
> Request".
> > >
> > >
> > > Thanks
> > > Anirudh
> > >
> > >
> > > On Wed, Jun 27, 2018 at 3:50 PM Hagay Lupesko 
> wrote:
> > >
> > > > Thank you everyone for your suggestions.
> > > > I will work with a committer to get this updated ASAP.
> > > >
> > > > On Mon, Jun 25, 2018 at 8:55 AM Marco de Abreu
> > > >  wrote:
> > > >
> > > > > +1 to renaming to Backend
> > > > >
> > > > > On Mon, Jun 25, 2018 at 10:13 AM Hagay Lupesko 
> > > > wrote:
> > > > >
> > > > > > Thanks Lin for your feedback.
> > > > > > Bumping again to get more feedback before concluding.
> > > > > >
> > > > > > On Fri, Jun 22, 2018 at 8:53 AM Lin Yuan 
> > > wrote:
> > > > > >
> > > > > > > I agree with Hagay. Using "Backend" as label makes it much
> easier
> > > to
> > > > > > track.
> > > > > > >  "C++" label only describes the language used in
> implementation,
> > > > > > "Backend"
> > > > > > > better describes the nature of the work (let's assume we change
> > the
> > > > > > backend
> > > > > > > implementation from C++ to other languages in the future).
> > > > > > >
> > > > > > > Lin
> > > > > > >
> > > > > > > On Fri, Jun 22, 2018 at 1:09 AM Hagay Lupesko <
> lupe...@gmail.com
> > >
> > > > > wrote:
> > > > > > >
> > > > > > > > Thanks everyone for chiming in and clarifying.
> > > > > > > > It seems that the "C++" label name is confusing for our
> > community
> > > > > since
> > > > > > > it
> > > > > > > > can be interpreted as both the CPP API and the backend...
> > > > > > > > As an anecdote, this issue [1
> > > > > > > > ] is
> > > > labeled
> > > > > > as
> > > > > > > > "C++" but is about the CPP API, not the backend.
> > > > > > > >
> > > > > > > > Should we just rename "C++" to "Backend" to avoid confusion?
> > > > > > > >
> > > > > > > > [1] https://github.com/apache/incubator-mxnet/issues/10937
> > > > > > > >
> > > > > > > > On Thu, Jun 21, 2018 at 12:39 PM Pedro Larroy <
> > > > > > > > pedro.larroy.li...@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Agree with Anirudh, they are different things. Maybe change
> > the
> > > > > "C++"
> > > > > > > > label
> > > > > > > > > to "backend" would be more informative?
> > > > > > > > >
> > > > > > > > > On Thu, Jun 21, 2018 at 12:11 PM Anirudh <
> > > anirudh2...@gmail.com>
> > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Hi Hagay,
> > > > > > > > > >
> > > > > > > > > > I think we should keep these two labels seperate since
> they
> > > > mean
> > > > > > > > > different
> > > > > > > > > > things.
> > > > > > > > > > The C++ label refers to the issue for MXNet backend and
> the
> > > CPP
> > > > > > > package
> > > > > > > > > > refers to the CPP language binding for mxnet.
> > > > > > > > > > We can still make C++ API great again irrespective by
> > > filtering
> > > > > out
> > > > > > > CPP
> > > > > > > > > > package issues :).
> > > > > > > > > >
> > > > > > > > > > Anirudh
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Thu, Jun 21, 2018 at 11:56 AM, Hagay Lupesko <
> > > > > lupe...@gmail.com
> > > > > > >
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Hey community,
> > > > > > > > > > >
> > > > > > > > > > > I was going over the open GitHub issues for MXNet, and
> > > > noticed
> > > > > > that
> > > > > > > > we
> > > > > > > > > > have
> > > > > > > > > > > two labels for the CPP API: "CPP package", "C++"
> > > > > > > > > > >
> > > > > > > > > > > Wanted to suggest we remove "CPP package" and just
> stick
> > to
> > > > > "C++"
> > > > > > > > > > > This will make it easier for the community to classify
> > > issues
> > > > > and
> > > > > > > > focus
> > > > > > > > > > on
> > > > > > > > > > > making the C++ API great again ;)
> > > > > > > > > > >
> > > > > > > > > > > Let me know if someone has any concerns, otherwise I
> will
> > > > find
> > > > > a
> > > > > > > > > > committer
> > > > > > > > > > > that I can work with to make this change.
> > > > > > > > > > >
> > > > > > > > > > > Thanks!
> > > > > > > > > > > Hagay
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: FW: Success at Apache: The Apache Way for Executives

[Hagay Lupesko]

Could not agree more Yasser - thanks for sharing!

On Tue, Jul 10, 2018 at 11:04 AM Tianqi Chen 
wrote:

> Totally agree with what being said here, as community strives to move
> forward it is important to be inclusive and communicative.  The same
> principle also applies beyond this mail-list, as we also need be inclusive
> and welcoming to contributors who contribute via github, write issues and
> use discuss forums.
>
> Tianqi
>
> On Mon, Jul 9, 2018 at 9:35 PM, Yasser Zamani 
> wrote:
>
> > I thought these could be great for our community so I shared them here.
> >
> > "The most important and first lesson I learned from the Apache Community
> > was to avoid short term gains that were unsustainable in the long term.
> > This very important core principle derives in part from the concept of
> > "community over code". It does not matter how much code you write, or how
> > good your code is if you cannot get along, compromise, and communicate
> > respectfully with your peers. The code does not write itself, its the
> > community behind it that keeps the code alive." Alex Karasulu, an
> > entrepreneur with over 25 years of experience said.
> >
> > Best Regards.
> >
> > >-Original Message-
> > >From: Sally Khudairi 
> > >Sent: Monday, July 9, 2018 8:00 PM
> > >To: Apache Announce List 
> > >Subject: Success at Apache: The Apache Way for Executives
> > >
> > >[this post is available online at https://s.apache.org/2Wg8 ]
> > >
> > >by Alex Karasulu
> > >
> > >I'm a long time member of the Apache Software Foundation and have been
> an
> > >executive officer of several corporations over the course of the past 20
> > years.
> > >I've co-founded several projects in the community and mentored several
> > others.
> > >
> > >The "Apache Way" has benefited several aspects of my life, however I
> never
> > >imagined it would help make me a better executive. Even non-technical
> > >executives, in organizations totally outside of the realm of technology,
> > can
> > >benefit from the Zen of the Apache Way.
> > >
> > >Life is hard when you're stupid
> > >
> > >I was involved in a number of early dot com startups as an executive,
> > however
> > >that was before my involvement with Apache and long before any exposure
> to
> > >the Apache Way. To this day, I remember how opportunistic decisions for
> > short
> > >term gains, the lack of collaboration, openness and communication kept
> > causing
> > >friction that made my job and ultimately my life much harder than it had
> > to be.
> > >
> > >Learning while on the job
> > >
> > >Exposure to the philosophy began early even while lurking on mailing
> > lists but
> > >picked up more while incubating the Apache Directory Project where I
> > worked
> > >with others to grow an active community. Meanwhile, I was the Chief
> > >Technology Officer of a large financial services company called Alliance
> > Capital
> > >Partners. It was 2002, and the first time I had to conduct myself as a
> > C-Suite
> > >executive in an enterprise that was obviously not a technology company.
> > >Incidentally, the lack of hands-on coding got me working on a pet
> project
> > that
> > >ultimately became the Apache Directory Server and Apache MINA. The
> project
> > >was medicine to keep me sane and technically up to date. Unbeknownst to
> > me,
> > >this would save my career, not as a developer, but as an executive.
> > >
> > >The Apache Way makes life easier
> > >
> > >The most important and first lesson I learned from the Apache Community
> > was to
> > >avoid short term gains that were unsustainable in the long term. This
> very
> > >important core principle derives in part from the concept of "community
> > over
> > >code". It does not matter how much code you write, or how good your code
> > is if
> > >you cannot get along, compromise, and communicate respectfully with your
> > >peers. The code does not write itself, its the community behind it that
> > keeps the
> > >code alive. Involving only the most technically proficient contributors
> > should
> > >never trump the need to build a sustainable community. I saw projects
> > often
> > >suffer from self-centered yet skilled coders added as committers for
> > short term
> > >gain at the detriment of a healthy sustainable community. So as a
> > corollary to
> > >community over code, avoid short term gains that get in the way of the
> > long term
> > >sustainability of an organization's culture. This has immense
> > applications for any
> > >executive in both technical and non-technical fields.
> > >
> > >While growing my new development organization in this financial services
> > >organization, I decided to avoid hiring people that seemed to be very
> > skilled
> > >technically but lacked the desire or social skills to collaborate with
> > others. Thanks
> > >to experiences at Apache, I could start telling them apart much better
> > than I did
> > >before. Also, I was calmer and less anxious when hiring to fill gaps on
> > the team. It
> >

CI is experiencing issues at the moment

[Anton Chernov]

Dear MXNet community,

We are currently experiencing some issues with the CI system [1] (the disk
space run full on the master).

We will update you shortly when the issue was resolved.

Best regards,
Anton Chernov

[1] https://github.com/apache/incubator-mxnet/issues/11654

CI is experiencing issues at the moment

[Anton Chernov]

Dear MXNet community,

We are currently experiencing some issues with the CI system [1] (the disk
space run full on the master).

We will update you shortly when the issue was resolved.

Best regards,
Anton Chernov

[1] https://github.com/apache/incubator-mxnet/issues/11654

Re: CI is experiencing issues at the moment

[Anton Chernov]

The issue has been resolved. We have retriggered the failed builds and
there is no need for any actions on your side. We will continue to monitor
the builds for any further failures.

Apologies for any inconvenience.

Best regards,
Anton

чт, 12 июл. 2018 г. в 11:31, Anton Chernov :

> Dear MXNet community,
>
> We are currently experiencing some issues with the CI system [1] (the disk
> space run full on the master).
>
> We will update you shortly when the issue was resolved.
>
> Best regards,
> Anton Chernov
>
> [1] https://github.com/apache/incubator-mxnet/issues/11654
>

Re: Disabling flaky tests

[Marco de Abreu]

Quick update: We are now at 27 disabled tests
https://github.com/apache/incubator-mxnet/issues?q=is%3Aopen+is%3Aissue+label%3A%22Disabled+test%22

-Marco

On Thu, Jun 28, 2018 at 2:31 AM Marco de Abreu 
wrote:

> Hello,
>
> we currently have a false-failure rate of about 59% in our CI. This leads
> to a lot of PRs failing due to flaky tests. We're currently in the process
> to fix problematic tests, but we're still not at a point which we can
> consider as stable.
>
> A few colleagues proposed to disable tests temporarily to increase the
> stability of the system. I know that this is heavily opposed by a lot of
> people including myself, but we're pretty much stalling our development due
> to these issues. Thus, I'd like to disable them for now and make them a
> release requirement. We currently have 12 disabled tests (ranging back to
> October 2017) and I'd like to add a few more.
>
> To keep track of disabled tests, I have added a new label [1]. If a test
> gets fixed, the issue will be closed and thus automatically disappear from
> the list.
>
> To address the concerns of the community about tests being disabled and
> then forgotten, I'd like to make it a release requirement for 1.3 that no
> tests are disabled. This means we will have reduced coverage temporarily,
> but it will not impact our customers since they will be re-enabled for the
> next release - this is basically a two-way door. On the other hand, we're
> improving the turnaround time for PRs and reduce the frustration level.
>
> By the way, we currently have an internal sprint running at Amazon which
> leads to everybody focussing on addressing flaky tests. This means that
> this state will not persist for long.
>
> Best regards,
> Marco
>
> [1]:
> https://github.com/apache/incubator-mxnet/issues?q=is%3Aopen+is%3Aissue+label%3A%22Disabled+test%22
>

Re: Squash/Merge PRs

[Anton Chernov]

Unfortunately there has been significant push back for small iterative PR's
and as a result they have grown substantially involving multiple
contributors, multiple commits, sometimes multiple branches to be worked on.

I fully agree and support all points that Jin raised:

1) Most contributions should be broken down into smallest possible PR's.
2) If a PR is small enough a single person can complete it.
3) If a majority of PR is done by someone, and there's some minor issue
he/she needs help with it could be done in a follow up PR by anybody,
including the reviewer.

Best regards,
Anton

чт, 12 июл. 2018 г. в 10:11, Hao Jin :

> +1 for Marco's proposal on using the co-author field. IMHO the usage of
> co-author field should not be that often, consider:
> 1) If a PR is so big that it needs multiple people to contribute a
> substantial part of it, why can't that PR be broken down into smaller PRs
> each submitted by single one of them?
> 2) If a PR is small enough (for example, < 300 lines), why can't a single
> person complete it?
> 3) If a majority of PR is done by someone, and there's some minor issue
> he/she needs help with(a small bug, incomplete doc), why can't that be done
> through code reviews?
> From the above 3 situations we can see that collaborations on individual
> PRs should not be quite often, but I do agree that it could still be
> necessary when someone lacks the related expertise/knowledge on some
> necessary part of that PR given that the required knowledge cannot be
> picked up in a short period of time.
>
> I do agree that keeping the commit histories of PRs clean is very important
> as it could be confusing when reviewing PRs, but that really depends on
> personal preferences (For my case, I usually do "git commit --amend" on
> trivial changes and get a new commit for bigger changes such as a
> checkpoint of my whole PR). With growing the community and attracting more
> contributors as a high priority for our project, I would prefer that we do
> not put even more burden on the contributors by asking them to manage and
> squash the commits themselves just for the not-so-often cases of having
> multiple contributors on a single PR.
> Best regards,
> Hao
>
> On Thu, Jul 12, 2018 at 12:35 AM, Marco de Abreu <
> marco.g.ab...@googlemail.com.invalid> wrote:
>
> > Hi Naveen,
> >
> > I'm in favour of the squashing, considering the number of commits in some
> > PRs and especially because of some people making commit messages a la
> "fix"
> > "fix" "fix" all the time. Additionally, it gets hard (not impossible,
> just
> > more inconvenient) to determine the atomic states of master - aka, which
> > commits are separate from each other. You should consider that
> intermediary
> > commits are unstable (fail CI) and thus it could be very hard to bisect
> > failures in future - and the commit history gets cluttered.
> >
> > As alternative, I'd like to suggest the co-author field for these cases.
> > Further documentation is available at
> > https://blog.github.com/2018-01-29-commit-together-with-co-authors/.
> >
> > I definitely agree with the second part. We should all lead by example
> and
> > maintain a high quality by keeping our commit messages clean and
> > meaningful. When I receive an email notification that a new commit has
> been
> > added and it only contains "fix" as title, it's not that helpful and also
> > it's hard to track the development of a PR overtime. E.g., why has
> > something been changed? Was there maybe a bug that we didn't cover with
> > tests but the author just hacked something to get it to work but the
> > problem still lays somewhere? We won't know that way and it makes it
> harder
> > for us to review.
> >
> > Best regards,
> > Marco
> >
> >
> > Naveen Swamy  schrieb am Do., 12. Juli 2018, 10:09:
> >
> > > Hi All,
> > >
> > > I am seeing that maintainers merge PRs into the repo, they are
> squashing
> > > the commits in the PR, which I understand and agree is to keep a sane
> > > commit history, however this is causing problem when there are multiple
> > > contributors involved on a PR(by contributing to a fork of the repo)
> this
> > > effectively removes credit for multiple contributors involved and shows
> > all
> > > code as authored by the contributor who created the PR.
> > >
> > > Can I request maintainers to not squash PRs if there are multiple
> > > contributors involved on the PR.
> > >
> > > Also on the same note, I request contributors(regardless of multiple
> > > contributors or not) to keep a clean commit history by squashing the
> > > commits and not push all your WIP commits to the PR. this will help us
> > keep
> > > our commit history clean and meaningful.
> > >
> > > Let me know your thoughts/better approach or If I have misunderstood
> how
> > > this works.
> > >
> > > Thanks, Naveen
> > >
> >
>

Re: [VOTE] Release MXNet version 1.2.1.RC1

[Indhu]

+1

Built from source. Tested few RNN samples on GPU. Works fine.

On Thu, Jul 12, 2018, 12:01 AM Haibin Lin  wrote:

> +1
> Built from source with cuda and dist kvstore. Ran dist_sync_kvstore.py
> nightly test and it passed.
>
> Best,
> Haibin
>
> On Wed, Jul 11, 2018 at 6:13 PM, Roshani Nagmote <
> roshaninagmo...@gmail.com>
> wrote:
>
> > Hi All,
> >
> > Could you please test and vote for this release? Voting will end tomorrow
> > by 5:50 pm PDT.
> >
> > Thanks,
> > Roshani
> >
> > On Mon, Jul 9, 2018 at 4:53 PM Roshani Nagmote <
> roshaninagmo...@gmail.com>
> > wrote:
> >
> > > Hi all,
> > >
> > > I would like to propose a vote to release Apache MXNet (incubating)
> > > version
> > > 1.2.1.RC1. Voting will start now (Monday, Jul 9th) and end at 5:50 PM
> > > PDT, Thursday, July 12th.
> > >
> > > Link to release candidate 1.2.1.rc1:
> > > *https://github.com/apache/incubator-mxnet/releases/tag/1.2.1.rc1
> > > *
> > >
> > > View this page, click on "Build from Source", and use the source code
> > > obtained from 1.2.1.rc1 tag:
> > > https://mxnet.incubator.apache.org/install/index.html
> > >
> > > (Note: The README.md points to the 1.2.1 tag and does not work at the
> > > moment.)
> > >
> > > Please remember to test first before voting accordingly:
> > >
> > > +1 = approve
> > > +0 = no opinion
> > > -1 = disapprove (provide reason)
> > >
> > > Thanks,
> > > Roshani
> > >
> >
>

Re: [VOTE] Release MXNet version 1.2.1.RC1

[sandeep krishnamurthy]

+1

Built from source. Tested on CPU and GPU with Keras-MXNet (ResNet and LSTM
examples), works as expected.

Best,
Sandeep

On Thu, Jul 12, 2018 at 7:10 AM Indhu  wrote:

> +1
>
> Built from source. Tested few RNN samples on GPU. Works fine.
>
> On Thu, Jul 12, 2018, 12:01 AM Haibin Lin 
> wrote:
>
> > +1
> > Built from source with cuda and dist kvstore. Ran dist_sync_kvstore.py
> > nightly test and it passed.
> >
> > Best,
> > Haibin
> >
> > On Wed, Jul 11, 2018 at 6:13 PM, Roshani Nagmote <
> > roshaninagmo...@gmail.com>
> > wrote:
> >
> > > Hi All,
> > >
> > > Could you please test and vote for this release? Voting will end
> tomorrow
> > > by 5:50 pm PDT.
> > >
> > > Thanks,
> > > Roshani
> > >
> > > On Mon, Jul 9, 2018 at 4:53 PM Roshani Nagmote <
> > roshaninagmo...@gmail.com>
> > > wrote:
> > >
> > > > Hi all,
> > > >
> > > > I would like to propose a vote to release Apache MXNet (incubating)
> > > > version
> > > > 1.2.1.RC1. Voting will start now (Monday, Jul 9th) and end at 5:50 PM
> > > > PDT, Thursday, July 12th.
> > > >
> > > > Link to release candidate 1.2.1.rc1:
> > > > *https://github.com/apache/incubator-mxnet/releases/tag/1.2.1.rc1
> > > > *
> > > >
> > > > View this page, click on "Build from Source", and use the source code
> > > > obtained from 1.2.1.rc1 tag:
> > > > https://mxnet.incubator.apache.org/install/index.html
> > > >
> > > > (Note: The README.md points to the 1.2.1 tag and does not work at the
> > > > moment.)
> > > >
> > > > Please remember to test first before voting accordingly:
> > > >
> > > > +1 = approve
> > > > +0 = no opinion
> > > > -1 = disapprove (provide reason)
> > > >
> > > > Thanks,
> > > > Roshani
> > > >
> > >
> >
>


-- 
Sandeep Krishnamurthy

Re: Squash/Merge PRs

[Aaron Markham]

 This is a great discussion, and close to my heart, because I want to
include more writers and editors in our community, and I'm struggling to
see how to best manage this. It seems like being the sole contributor on a
feature is like an engineer's Lone Ranger badge of pride! I feel like it
should be a red flag.

I work in collaboration with dozens of engineers to improve their
documentation, explain their features, change flows to improve user
experience, and sometimes fix bugs and write code. When the PR's docs has
great coverage, is clear, and not loaded with bad grammar and spelling
mistakes, I will put comments in a review. But sometimes there needs to be
a complete rework such that hundreds of review comments isn't feasible, and
they can't be properly addressed. In a lot of these cases, I commit my
changes to someone else's fork. Now I know the people I work with on their
PRs appreciate my help, but when all of this work gets squashed down to one
commit, I'm pretty much regularly getting squashed out. I'm not sure who
else is in this boat, but does the community recognize our contributions
when this is the general mode of operation?

Regarding co-author - I'm not sure how people would feel about me being a
co-author on their work. Documentation and clarity in your work product is
important, but people's views on their personal *code* contribution seems
to be more important than the overall code & feature quality itself when
docs are part of the package. I feel that if I do follow-on PRs instead of
fixing things before they are merged, that we would be releasing incorrect,
incomplete, and inferior product. But, in absence of a better solution,
maybe that's the pill we have to swallow.

-1 on lots of small PRs (until we expand our range of committers and reduce
the latency in reviews and merges).
+1 on improving the quality of commit messages, so we don't have to squash
& merge all of the time.
+1 on improving the practice of better commit & merge management so that
the commit history is concise and meaningful. (I'm guilty of this, and
certainly need to improve here.)
+1 on co-author - assuming that's what most everyone thinks is a good
solution for now. I'm unclear on how this gets managed though.

Cheers,
Aaron


On Thu, Jul 12, 2018 at 5:19 AM, Anton Chernov  wrote:

> Unfortunately there has been significant push back for small iterative PR's
> and as a result they have grown substantially involving multiple
> contributors, multiple commits, sometimes multiple branches to be worked
> on.
>
> I fully agree and support all points that Jin raised:
>
> 1) Most contributions should be broken down into smallest possible PR's.
> 2) If a PR is small enough a single person can complete it.
> 3) If a majority of PR is done by someone, and there's some minor issue
> he/she needs help with it could be done in a follow up PR by anybody,
> including the reviewer.
>
> Best regards,
> Anton
>
> чт, 12 июл. 2018 г. в 10:11, Hao Jin :
>
> > +1 for Marco's proposal on using the co-author field. IMHO the usage of
> > co-author field should not be that often, consider:
> > 1) If a PR is so big that it needs multiple people to contribute a
> > substantial part of it, why can't that PR be broken down into smaller PRs
> > each submitted by single one of them?
> > 2) If a PR is small enough (for example, < 300 lines), why can't a single
> > person complete it?
> > 3) If a majority of PR is done by someone, and there's some minor issue
> > he/she needs help with(a small bug, incomplete doc), why can't that be
> done
> > through code reviews?
> > From the above 3 situations we can see that collaborations on individual
> > PRs should not be quite often, but I do agree that it could still be
> > necessary when someone lacks the related expertise/knowledge on some
> > necessary part of that PR given that the required knowledge cannot be
> > picked up in a short period of time.
> >
> > I do agree that keeping the commit histories of PRs clean is very
> important
> > as it could be confusing when reviewing PRs, but that really depends on
> > personal preferences (For my case, I usually do "git commit --amend" on
> > trivial changes and get a new commit for bigger changes such as a
> > checkpoint of my whole PR). With growing the community and attracting
> more
> > contributors as a high priority for our project, I would prefer that we
> do
> > not put even more burden on the contributors by asking them to manage and
> > squash the commits themselves just for the not-so-often cases of having
> > multiple contributors on a single PR.
> > Best regards,
> > Hao
> >
> > On Thu, Jul 12, 2018 at 12:35 AM, Marco de Abreu <
> > marco.g.ab...@googlemail.com.invalid> wrote:
> >
> > > Hi Naveen,
> > >
> > > I'm in favour of the squashing, considering the number of commits in
> some
> > > PRs and especially because of some people making commit messages a la
> > "fix"
> > > "fix" "fix" all the time. Additionally, it gets hard (not impossible,
>

looking for collaborator with write permission to update http://incubator.apache.org/projects/mxnet.html

[Steffen Rochel]

http://incubator.apache.org/projects/mxnet.html is outdated and missing
information like mentors, committers, poddling reports, user@ etc.
Anybody with write permission interested to collaborate to update the page?

Regards,
Steffen

ICLAs?

[Sergio Fernández]

Hi,

one detail I've notices: is the Podling collecting all ICLA when people
contribute to the project?

I can' find traces for most of the folks in this list:

https://github.com/apache/incubator-mxnet/blob/master/CONTRIBUTORS.md

Because that's a minor, but important, detail for the viability of the
project.

Cheers,

Re: ICLAs?

[Marco de Abreu]

Hi Sergio,

we are only collecting ICLAs from people if they become a committer.
Otherwise, we don't request any.

-Marco

On Thu, Jul 12, 2018 at 8:07 PM Sergio Fernández  wrote:

> Hi,
>
> one detail I've notices: is the Podling collecting all ICLA when people
> contribute to the project?
>
> I can' find traces for most of the folks in this list:
>
> https://github.com/apache/incubator-mxnet/blob/master/CONTRIBUTORS.md
>
> Because that's a minor, but important, detail for the viability of the
> project.
>
> Cheers,
>

Re: [VOTE] Release MXNet version 1.2.1.RC1

[Jun Wu]

+1 Built from source and ran the gpu unit tests.

On Thu, Jul 12, 2018 at 8:01 AM sandeep krishnamurthy <
sandeep.krishn...@gmail.com> wrote:

> +1
>
> Built from source. Tested on CPU and GPU with Keras-MXNet (ResNet and LSTM
> examples), works as expected.
>
> Best,
> Sandeep
>
> On Thu, Jul 12, 2018 at 7:10 AM Indhu  wrote:
>
> > +1
> >
> > Built from source. Tested few RNN samples on GPU. Works fine.
> >
> > On Thu, Jul 12, 2018, 12:01 AM Haibin Lin 
> > wrote:
> >
> > > +1
> > > Built from source with cuda and dist kvstore. Ran dist_sync_kvstore.py
> > > nightly test and it passed.
> > >
> > > Best,
> > > Haibin
> > >
> > > On Wed, Jul 11, 2018 at 6:13 PM, Roshani Nagmote <
> > > roshaninagmo...@gmail.com>
> > > wrote:
> > >
> > > > Hi All,
> > > >
> > > > Could you please test and vote for this release? Voting will end
> > tomorrow
> > > > by 5:50 pm PDT.
> > > >
> > > > Thanks,
> > > > Roshani
> > > >
> > > > On Mon, Jul 9, 2018 at 4:53 PM Roshani Nagmote <
> > > roshaninagmo...@gmail.com>
> > > > wrote:
> > > >
> > > > > Hi all,
> > > > >
> > > > > I would like to propose a vote to release Apache MXNet (incubating)
> > > > > version
> > > > > 1.2.1.RC1. Voting will start now (Monday, Jul 9th) and end at 5:50
> PM
> > > > > PDT, Thursday, July 12th.
> > > > >
> > > > > Link to release candidate 1.2.1.rc1:
> > > > > *https://github.com/apache/incubator-mxnet/releases/tag/1.2.1.rc1
> > > > >  >*
> > > > >
> > > > > View this page, click on "Build from Source", and use the source
> code
> > > > > obtained from 1.2.1.rc1 tag:
> > > > > https://mxnet.incubator.apache.org/install/index.html
> > > > >
> > > > > (Note: The README.md points to the 1.2.1 tag and does not work at
> the
> > > > > moment.)
> > > > >
> > > > > Please remember to test first before voting accordingly:
> > > > >
> > > > > +1 = approve
> > > > > +0 = no opinion
> > > > > -1 = disapprove (provide reason)
> > > > >
> > > > > Thanks,
> > > > > Roshani
> > > > >
> > > >
> > >
> >
>
>
> --
> Sandeep Krishnamurthy
>

Re: Proposal to release the Examples for Scala in V1.3

[YiZhi Liu]

Agree to make incremental improvements. As long as the changes do not
change the current states of memory leak, but improve the documents
and demonstrate the way to use type-safe apis, I think it is fair to
merge into v1.3.
On Wed, Jul 11, 2018 at 4:43 PM Naveen Swamy  wrote:
>
> Qing, its great that you are working on improving the Scala Examples with
> documentation and tests.
> Ideally, we shouldn't have any memory leaks..it erodes trust with our
> users, however I understand it can take significant time and debugging
> effort to resolve them. Given that these leaks already exist, may be should
> call out on the documentation that this is a known issue and we will work
> on it.
> IMO for this case making incremental improvements to examples makes sense.
>
> I would like to hear what others think.
> -Naveen
>
> On Wed, Jul 11, 2018 at 3:47 PM, Qing Lan  wrote:
>
> > Hi all,
> >
> > I would like to propose the release plan for MXNet Scala examples in V1.3.
> > Currently, the examples in the main repository are not maintained for a
> > long time. I have spent some time to use the improved Scala API (known as
> > the .api) to improve the examples with documentation to run and add CI
> > tests. However, I am facing the difficulties to resolve memory leaks as
> > most of the examples did not contains memory leak fixes. It crashes the CI
> > because of that. We can temporarily disable the CI test for some of the
> > examples and release them with 1.3 and enable them once we have a better GC
> > in MXNet Scala. Here is a brief Pros and Cons for this release:
> >
> > Pros:
> >
> >   *   A good set of demos on how to use improved Training API
> >   *   Examples are fixed with full documentation to help to run them
> >
> > Cons:
> >
> >   *   Examples contains the memory leak issues may cause problems
> >
> > Please kindly share your ideas in this thread and I am really appreciate
> > for your help.
> >
> > Thanks,
> > Qing
> >



-- 
Yizhi Liu
DMLC member
Amazon Web Services
Vancouver, Canada

Access Permission of MXNet label bot

[Yuelin Zhang]

Hi,

I am working to improve the GitHub issue triage process by creating a label
bot(more info here

on
the cwiki), I have initial version of label bot ready. I would like to get
some opinions about access permission of MXNet label bot.

Right now, all issues in MXNet repo are manually labeled. The process looks
like below:
First, contributors/committers go through the issues to triage them and
suggest labels and add comment on the issue requesting @committer to add
labels.

This process will cause notification spam to both committers and users. The
long gap between user creating an issue and we labelling them will cause
the process time consuming and not very smooth.

We want to simplify/automate this issue labeling process. Right now an
initial version of the label bot which can:

   1.  Send issue report daily. This report will show how many issue
   open/closed, list uncommented/unlabeled issues and show an pie chart of
   labels added in a week. Sample report here
   

   .
   2.  Generate a spread sheet of unlabeled issues with recommended labels.
   A contributor will open the sheet and fill in labels with reference of
   bot's recommendations. In this case, contributor can deal with all
   unlabeled issues at a time. Sample sheet here
   

   .
   3.  Read labels filled in that sheet and apply labels to GitHub issues.
   (tested on my personal Github repo)


This bot can be triggered daily so that all issues will be labeled in one
day without notification spam.

*However,  this bot doesn't have access to add labels. We have two options:*

- Use a committer's Oauth token with limited scope. So far according to my
research, the most limited scope is "public_repo", this contains access to
code. Except this one, Github doesn't have smaller scope available to add
labels. Available scopes here

.

- Create a bot account having minimum permissions. For this, we will need
an account to be created from Apache Infrastructure with proper access and
they can control the access for the account through secret manager
 .
Having a bot account is beneficial for future work, not only for labelling
but also other automatic processes.

Please let me know if you have any other ideas to do this.

Thanks,
Cathy

Re: Proposal to release the Examples for Scala in V1.3

[Marco de Abreu]

Hi Qing,

thanks a lot for your efforts around the Scala examples and to assist us
getting the Scala API to a broader user base! This is a great user-facing
approach!

The following might not be in the current course of how we handle examples
in Python, but let me elaborate: I have seen a lot of problems in the last
months related to examples in Python in the last months that could have
been avoided by testing them in integration tests. These errors included
syntax errors, typos, wrong logic, outdated APIs or other more
context-related errors. Thus, I'd like to strive for full test coverage of
our examples in the long term. I know that we can't get this done within a
single night, but since you are now reworking the way our examples work in
Scala, I'd like to kindly request to assess whether it's possible to
include testing of Scala examples in your plan right from the start. This
will ensure that we have a good first impression with our users, increases
our overall test coverage and also reduces the maintenance overhead we are
having with examples breaking without us knowing.

I think the memory leaks are adjacent problems and that examples are a good
way to make them visible. Since they are already there, we shouldn't block
ourselves from writing and publishing examples. Our users would encounter
them anyways, but by making the examples, we can properly document and
track them ahead of time. The big advantage right now would be that we
could mark these things as known problems in our patch notes and thus our
users would know that we are aware of them and that we are going to fix
them by (hopefully) the following release.

Best regards,
Marco

On Thu, Jul 12, 2018 at 8:41 PM YiZhi Liu  wrote:

> Agree to make incremental improvements. As long as the changes do not
> change the current states of memory leak, but improve the documents
> and demonstrate the way to use type-safe apis, I think it is fair to
> merge into v1.3.
> On Wed, Jul 11, 2018 at 4:43 PM Naveen Swamy  wrote:
> >
> > Qing, its great that you are working on improving the Scala Examples with
> > documentation and tests.
> > Ideally, we shouldn't have any memory leaks..it erodes trust with our
> > users, however I understand it can take significant time and debugging
> > effort to resolve them. Given that these leaks already exist, may be
> should
> > call out on the documentation that this is a known issue and we will work
> > on it.
> > IMO for this case making incremental improvements to examples makes
> sense.
> >
> > I would like to hear what others think.
> > -Naveen
> >
> > On Wed, Jul 11, 2018 at 3:47 PM, Qing Lan  wrote:
> >
> > > Hi all,
> > >
> > > I would like to propose the release plan for MXNet Scala examples in
> V1.3.
> > > Currently, the examples in the main repository are not maintained for a
> > > long time. I have spent some time to use the improved Scala API (known
> as
> > > the .api) to improve the examples with documentation to run and add CI
> > > tests. However, I am facing the difficulties to resolve memory leaks as
> > > most of the examples did not contains memory leak fixes. It crashes
> the CI
> > > because of that. We can temporarily disable the CI test for some of the
> > > examples and release them with 1.3 and enable them once we have a
> better GC
> > > in MXNet Scala. Here is a brief Pros and Cons for this release:
> > >
> > > Pros:
> > >
> > >   *   A good set of demos on how to use improved Training API
> > >   *   Examples are fixed with full documentation to help to run them
> > >
> > > Cons:
> > >
> > >   *   Examples contains the memory leak issues may cause problems
> > >
> > > Please kindly share your ideas in this thread and I am really
> appreciate
> > > for your help.
> > >
> > > Thanks,
> > > Qing
> > >
>
>
>
> --
> Yizhi Liu
> DMLC member
> Amazon Web Services
> Vancouver, Canada
>

[DISCUSS] Subscribe dev@ to Github Activities?

[Sheng Zha]

Hi all,

Should we subscribe dev list to github updates on mxnet repo? Both github
issues/PRs and the dev list are intended for technical discussions and in
that aspect largely share the same goal. Since MXNet has most activity
github, this could help dev@ to become more active. Some pros and cons:

Pros:
- There have been many high quality discussions that happen on github to
which the dev list can benefit.
- Replies on update emails are reflected on the specific issue/PR.
- Users can also choose to click on the link and go to github to
participate in discussion.
- We still have the ability to carry out dev@ only conversation.

Cons:
- Higher volume on dev list.
- Some discussions might not be suitable for dev@. (though I can't think of
why such conversation should happen on github either)

-sz

Re: Access Permission of MXNet label bot

[Marco de Abreu]

Hello Cathy,

unfortunately, we're not allowed to use bot accounts at Apache.

An option we have is that we run your bot in our infrastructure with the
credentials of a committer with the permission you have mentioned. The only
restriction would be that you would not be able to access that server
because the credentials are confidential user data of a committer. Would
this work for you?

Best regards,
Marco

On Thu, Jul 12, 2018 at 8:57 PM Yuelin Zhang 
wrote:

> Hi,
>
> I am working to improve the GitHub issue triage process by creating a label
> bot(more info here
> <
> https://cwiki.apache.org/confluence/display/MXNET/Deep+Learning+Based+GitHub+Label+Bot
> >
> on
> the cwiki), I have initial version of label bot ready. I would like to get
> some opinions about access permission of MXNet label bot.
>
> Right now, all issues in MXNet repo are manually labeled. The process looks
> like below:
> First, contributors/committers go through the issues to triage them and
> suggest labels and add comment on the issue requesting @committer to add
> labels.
>
> This process will cause notification spam to both committers and users. The
> long gap between user creating an issue and we labelling them will cause
> the process time consuming and not very smooth.
>
> We want to simplify/automate this issue labeling process. Right now an
> initial version of the label bot which can:
>
>1.  Send issue report daily. This report will show how many issue
>open/closed, list uncommented/unlabeled issues and show an pie chart of
>labels added in a week. Sample report here
><
> https://cwiki.apache.org/confluence/display/MXNET/Deep+Learning+Based+GitHub+Label+Bot#DeepLearningBasedGitHubLabelBot-SampleIssueReport
> >
>.
>2.  Generate a spread sheet of unlabeled issues with recommended labels.
>A contributor will open the sheet and fill in labels with reference of
>bot's recommendations. In this case, contributor can deal with all
>unlabeled issues at a time. Sample sheet here
><
> https://cwiki.apache.org/confluence/display/MXNET/Deep+Learning+Based+GitHub+Label+Bot#DeepLearningBasedGitHubLabelBot-SampleSpreadSheet
> >
>.
>3.  Read labels filled in that sheet and apply labels to GitHub issues.
>(tested on my personal Github repo)
>
>
> This bot can be triggered daily so that all issues will be labeled in one
> day without notification spam.
>
> *However,  this bot doesn't have access to add labels. We have two
> options:*
>
> - Use a committer's Oauth token with limited scope. So far according to my
> research, the most limited scope is "public_repo", this contains access to
> code. Except this one, Github doesn't have smaller scope available to add
> labels. Available scopes here
> <
> https://developer.github.com/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/
> >
> .
>
> - Create a bot account having minimum permissions. For this, we will need
> an account to be created from Apache Infrastructure with proper access and
> they can control the access for the account through secret manager
>  .
> Having a bot account is beneficial for future work, not only for labelling
> but also other automatic processes.
>
> Please let me know if you have any other ideas to do this.
>
> Thanks,
> Cathy
>

Re: Squash/Merge PRs

[Hao Jin]

Hi Aaron,
To be fair, this discussion has nothing to do with "pride" of SDEs, but
rather a discussion on what is a better software engineering practice for
the project. Breaking a large project into smaller tasks is a good software
engineering practice. This article(https://arxiv.org/pdf/1702.01715.pdf) on
Google's software engineering practice says: "Engineers are encouraged to
keep each individual change small​, with larger changes preferably broken
into a series of smaller changes that a reviewer can easily review in one
go.". If you have concerns or your comments on this practice, we can take
the discussion offline. On the other hand, an important spirit of Apache
community is that "one must interact with others, and share vision and
knowledge"(https://community.apache.org/contributors/), if you observed
that a majority of the contributors have serious problems with their
writing maybe you can share some tips and hints on how to write better
documentations, in that way not only a lot of us within the community can
have some growth but also you can save some time for writing more good
documentations and blogposts for MXNet, don't you think so? Or, if you only
have to fix the doc for someone once in a while, I definitely agree that
you should be given the credit for that, and that's where the co-author
field can be useful, which was exactly what I was saying in my previous
email. Thanks!
Hao

On Thu, Jul 12, 2018 at 8:16 AM, Aaron Markham 
wrote:

>  This is a great discussion, and close to my heart, because I want to
> include more writers and editors in our community, and I'm struggling to
> see how to best manage this. It seems like being the sole contributor on a
> feature is like an engineer's Lone Ranger badge of pride! I feel like it
> should be a red flag.
>
> I work in collaboration with dozens of engineers to improve their
> documentation, explain their features, change flows to improve user
> experience, and sometimes fix bugs and write code. When the PR's docs has
> great coverage, is clear, and not loaded with bad grammar and spelling
> mistakes, I will put comments in a review. But sometimes there needs to be
> a complete rework such that hundreds of review comments isn't feasible, and
> they can't be properly addressed. In a lot of these cases, I commit my
> changes to someone else's fork. Now I know the people I work with on their
> PRs appreciate my help, but when all of this work gets squashed down to one
> commit, I'm pretty much regularly getting squashed out. I'm not sure who
> else is in this boat, but does the community recognize our contributions
> when this is the general mode of operation?
>
> Regarding co-author - I'm not sure how people would feel about me being a
> co-author on their work. Documentation and clarity in your work product is
> important, but people's views on their personal *code* contribution seems
> to be more important than the overall code & feature quality itself when
> docs are part of the package. I feel that if I do follow-on PRs instead of
> fixing things before they are merged, that we would be releasing incorrect,
> incomplete, and inferior product. But, in absence of a better solution,
> maybe that's the pill we have to swallow.
>
> -1 on lots of small PRs (until we expand our range of committers and reduce
> the latency in reviews and merges).
> +1 on improving the quality of commit messages, so we don't have to squash
> & merge all of the time.
> +1 on improving the practice of better commit & merge management so that
> the commit history is concise and meaningful. (I'm guilty of this, and
> certainly need to improve here.)
> +1 on co-author - assuming that's what most everyone thinks is a good
> solution for now. I'm unclear on how this gets managed though.
>
> Cheers,
> Aaron
>
>
> On Thu, Jul 12, 2018 at 5:19 AM, Anton Chernov 
> wrote:
>
> > Unfortunately there has been significant push back for small iterative
> PR's
> > and as a result they have grown substantially involving multiple
> > contributors, multiple commits, sometimes multiple branches to be worked
> > on.
> >
> > I fully agree and support all points that Jin raised:
> >
> > 1) Most contributions should be broken down into smallest possible PR's.
> > 2) If a PR is small enough a single person can complete it.
> > 3) If a majority of PR is done by someone, and there's some minor issue
> > he/she needs help with it could be done in a follow up PR by anybody,
> > including the reviewer.
> >
> > Best regards,
> > Anton
> >
> > чт, 12 июл. 2018 г. в 10:11, Hao Jin :
> >
> > > +1 for Marco's proposal on using the co-author field. IMHO the usage of
> > > co-author field should not be that often, consider:
> > > 1) If a PR is so big that it needs multiple people to contribute a
> > > substantial part of it, why can't that PR be broken down into smaller
> PRs
> > > each submitted by single one of them?
> > > 2) If a PR is small enough (for example, < 300 lines), why can't a
> single
> > > p

Re: Proposal to release the Examples for Scala in V1.3

[Qing Lan]

Hi Marco,

Currently all Scala examples I have changed contains test coverage on CI (in 
the example/src/test/). It's been temporarily disabled because of the memory 
leaks.

I would also like to raise a discussion on a general standard for testing 
examples, this is what Scala side doing:

1. For small training examples we can finish them and check the dev accuracy
2. For big training examples, we do 5-10 Epoch to check it is runnable
3. For trivial examples (like neural style), we check it is runnable
4. For inference examples and classification specifically, we run with several 
test cases to measure if it can get the result correctly.

Thanks,
Qing

On 7/12/18, 11:00 AM, "Marco de Abreu"  
wrote:

Hi Qing,

thanks a lot for your efforts around the Scala examples and to assist us
getting the Scala API to a broader user base! This is a great user-facing
approach!

The following might not be in the current course of how we handle examples
in Python, but let me elaborate: I have seen a lot of problems in the last
months related to examples in Python in the last months that could have
been avoided by testing them in integration tests. These errors included
syntax errors, typos, wrong logic, outdated APIs or other more
context-related errors. Thus, I'd like to strive for full test coverage of
our examples in the long term. I know that we can't get this done within a
single night, but since you are now reworking the way our examples work in
Scala, I'd like to kindly request to assess whether it's possible to
include testing of Scala examples in your plan right from the start. This
will ensure that we have a good first impression with our users, increases
our overall test coverage and also reduces the maintenance overhead we are
having with examples breaking without us knowing.

I think the memory leaks are adjacent problems and that examples are a good
way to make them visible. Since they are already there, we shouldn't block
ourselves from writing and publishing examples. Our users would encounter
them anyways, but by making the examples, we can properly document and
track them ahead of time. The big advantage right now would be that we
could mark these things as known problems in our patch notes and thus our
users would know that we are aware of them and that we are going to fix
them by (hopefully) the following release.

Best regards,
Marco

On Thu, Jul 12, 2018 at 8:41 PM YiZhi Liu  wrote:

> Agree to make incremental improvements. As long as the changes do not
> change the current states of memory leak, but improve the documents
> and demonstrate the way to use type-safe apis, I think it is fair to
> merge into v1.3.
> On Wed, Jul 11, 2018 at 4:43 PM Naveen Swamy  wrote:
> >
> > Qing, its great that you are working on improving the Scala Examples 
with
> > documentation and tests.
> > Ideally, we shouldn't have any memory leaks..it erodes trust with our
> > users, however I understand it can take significant time and debugging
> > effort to resolve them. Given that these leaks already exist, may be
> should
> > call out on the documentation that this is a known issue and we will 
work
> > on it.
> > IMO for this case making incremental improvements to examples makes
> sense.
> >
> > I would like to hear what others think.
> > -Naveen
> >
> > On Wed, Jul 11, 2018 at 3:47 PM, Qing Lan  wrote:
> >
> > > Hi all,
> > >
> > > I would like to propose the release plan for MXNet Scala examples in
> V1.3.
> > > Currently, the examples in the main repository are not maintained for 
a
> > > long time. I have spent some time to use the improved Scala API (known
> as
> > > the .api) to improve the examples with documentation to run and add CI
> > > tests. However, I am facing the difficulties to resolve memory leaks 
as
> > > most of the examples did not contains memory leak fixes. It crashes
> the CI
> > > because of that. We can temporarily disable the CI test for some of 
the
> > > examples and release them with 1.3 and enable them once we have a
> better GC
> > > in MXNet Scala. Here is a brief Pros and Cons for this release:
> > >
> > > Pros:
> > >
> > >   *   A good set of demos on how to use improved Training API
> > >   *   Examples are fixed with full documentation to help to run them
> > >
> > > Cons:
> > >
> > >   *   Examples contains the memory leak issues may cause problems
> > >
> > > Please kindly share your ideas in this thread and I am really
> appreciate
> > > for your help.
> > >
> > > Thanks,
> > > Qing
> > >
>
>
>
> --
> Yizhi Liu
> DMLC member
> Amazon Web Services
> Vancouver, Canada
>

Re: Access Permission of MXNet label bot

[Qing Lan]

I think putting in the Infra can be a really good solution. 
We do not expose the credential to the outside and we can make sure it can be 
run in a timely manner.

Thanks,
Qing

On 7/12/18, 11:11 AM, "Marco de Abreu"  
wrote:

Hello Cathy,

unfortunately, we're not allowed to use bot accounts at Apache.

An option we have is that we run your bot in our infrastructure with the
credentials of a committer with the permission you have mentioned. The only
restriction would be that you would not be able to access that server
because the credentials are confidential user data of a committer. Would
this work for you?

Best regards,
Marco

On Thu, Jul 12, 2018 at 8:57 PM Yuelin Zhang 
wrote:

> Hi,
>
> I am working to improve the GitHub issue triage process by creating a 
label
> bot(more info here
> <
> 
https://cwiki.apache.org/confluence/display/MXNET/Deep+Learning+Based+GitHub+Label+Bot
> >
> on
> the cwiki), I have initial version of label bot ready. I would like to get
> some opinions about access permission of MXNet label bot.
>
> Right now, all issues in MXNet repo are manually labeled. The process 
looks
> like below:
> First, contributors/committers go through the issues to triage them and
> suggest labels and add comment on the issue requesting @committer to add
> labels.
>
> This process will cause notification spam to both committers and users. 
The
> long gap between user creating an issue and we labelling them will cause
> the process time consuming and not very smooth.
>
> We want to simplify/automate this issue labeling process. Right now an
> initial version of the label bot which can:
>
>1.  Send issue report daily. This report will show how many issue
>open/closed, list uncommented/unlabeled issues and show an pie chart of
>labels added in a week. Sample report here
><
> 
https://cwiki.apache.org/confluence/display/MXNET/Deep+Learning+Based+GitHub+Label+Bot#DeepLearningBasedGitHubLabelBot-SampleIssueReport
> >
>.
>2.  Generate a spread sheet of unlabeled issues with recommended 
labels.
>A contributor will open the sheet and fill in labels with reference of
>bot's recommendations. In this case, contributor can deal with all
>unlabeled issues at a time. Sample sheet here
><
> 
https://cwiki.apache.org/confluence/display/MXNET/Deep+Learning+Based+GitHub+Label+Bot#DeepLearningBasedGitHubLabelBot-SampleSpreadSheet
> >
>.
>3.  Read labels filled in that sheet and apply labels to GitHub issues.
>(tested on my personal Github repo)
>
>
> This bot can be triggered daily so that all issues will be labeled in one
> day without notification spam.
>
> *However,  this bot doesn't have access to add labels. We have two
> options:*
>
> - Use a committer's Oauth token with limited scope. So far according to my
> research, the most limited scope is "public_repo", this contains access to
> code. Except this one, Github doesn't have smaller scope available to add
> labels. Available scopes here
> <
> 
https://developer.github.com/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/
> >
> .
>
> - Create a bot account having minimum permissions. For this, we will need
> an account to be created from Apache Infrastructure with proper access and
> they can control the access for the account through secret manager
>  .
> Having a bot account is beneficial for future work, not only for labelling
> but also other automatic processes.
>
> Please let me know if you have any other ideas to do this.
>
> Thanks,
> Cathy
>

Re: Squash/Merge PRs

[Aaron Markham]

My point was about collaboration, or the lack thereof, and how the tooling
and apparent rewards from contribution statistics can reinforce lone ranger
behavior. People can and should be proud of their work, but why does it
have to be alone? Working within the context of a team is something to be
proud of too, but if your stats and standing are graded by how the commits
and merges land, and counting lines of code, then incentives of the system
are skewed.
How do we go about implementing the co-author process? It sounds like
something worth doing!

On Thu, Jul 12, 2018 at 11:15 AM, Hao Jin  wrote:

> Hi Aaron,
> To be fair, this discussion has nothing to do with "pride" of SDEs, but
> rather a discussion on what is a better software engineering practice for
> the project. Breaking a large project into smaller tasks is a good software
> engineering practice. This article(https://arxiv.org/pdf/1702.01715.pdf)
> on
> Google's software engineering practice says: "Engineers are encouraged to
> keep each individual change small​, with larger changes preferably broken
> into a series of smaller changes that a reviewer can easily review in one
> go.". If you have concerns or your comments on this practice, we can take
> the discussion offline. On the other hand, an important spirit of Apache
> community is that "one must interact with others, and share vision and
> knowledge"(https://community.apache.org/contributors/), if you observed
> that a majority of the contributors have serious problems with their
> writing maybe you can share some tips and hints on how to write better
> documentations, in that way not only a lot of us within the community can
> have some growth but also you can save some time for writing more good
> documentations and blogposts for MXNet, don't you think so? Or, if you only
> have to fix the doc for someone once in a while, I definitely agree that
> you should be given the credit for that, and that's where the co-author
> field can be useful, which was exactly what I was saying in my previous
> email. Thanks!
> Hao
>
> On Thu, Jul 12, 2018 at 8:16 AM, Aaron Markham 
> wrote:
>
> >  This is a great discussion, and close to my heart, because I want to
> > include more writers and editors in our community, and I'm struggling to
> > see how to best manage this. It seems like being the sole contributor on
> a
> > feature is like an engineer's Lone Ranger badge of pride! I feel like it
> > should be a red flag.
> >
> > I work in collaboration with dozens of engineers to improve their
> > documentation, explain their features, change flows to improve user
> > experience, and sometimes fix bugs and write code. When the PR's docs has
> > great coverage, is clear, and not loaded with bad grammar and spelling
> > mistakes, I will put comments in a review. But sometimes there needs to
> be
> > a complete rework such that hundreds of review comments isn't feasible,
> and
> > they can't be properly addressed. In a lot of these cases, I commit my
> > changes to someone else's fork. Now I know the people I work with on
> their
> > PRs appreciate my help, but when all of this work gets squashed down to
> one
> > commit, I'm pretty much regularly getting squashed out. I'm not sure who
> > else is in this boat, but does the community recognize our contributions
> > when this is the general mode of operation?
> >
> > Regarding co-author - I'm not sure how people would feel about me being a
> > co-author on their work. Documentation and clarity in your work product
> is
> > important, but people's views on their personal *code* contribution seems
> > to be more important than the overall code & feature quality itself when
> > docs are part of the package. I feel that if I do follow-on PRs instead
> of
> > fixing things before they are merged, that we would be releasing
> incorrect,
> > incomplete, and inferior product. But, in absence of a better solution,
> > maybe that's the pill we have to swallow.
> >
> > -1 on lots of small PRs (until we expand our range of committers and
> reduce
> > the latency in reviews and merges).
> > +1 on improving the quality of commit messages, so we don't have to
> squash
> > & merge all of the time.
> > +1 on improving the practice of better commit & merge management so that
> > the commit history is concise and meaningful. (I'm guilty of this, and
> > certainly need to improve here.)
> > +1 on co-author - assuming that's what most everyone thinks is a good
> > solution for now. I'm unclear on how this gets managed though.
> >
> > Cheers,
> > Aaron
> >
> >
> > On Thu, Jul 12, 2018 at 5:19 AM, Anton Chernov 
> > wrote:
> >
> > > Unfortunately there has been significant push back for small iterative
> > PR's
> > > and as a result they have grown substantially involving multiple
> > > contributors, multiple commits, sometimes multiple branches to be
> worked
> > > on.
> > >
> > > I fully agree and support all points that Jin raised:
> > >
> > > 1) Most contributions should be brok

Re: Squash/Merge PRs

[Marco de Abreu]

As of now it will require the usage of a merge bot as far as I understand
this issue: https://github.com/python/miss-islington/issues/16. Instead of
using the web interface do merge, we'd then trigger the bot to do the merge
on our behalf. There are pre-made solutions on the internet we might be
able to leverage, but it would take some time to get into it and adapt our
process.

Additionally, GitHub has this feature request tracked internally. Let's see
when they get to add it.

-Marco



Aaron Markham  schrieb am Do., 12. Juli 2018,
21:33:

> My point was about collaboration, or the lack thereof, and how the tooling
> and apparent rewards from contribution statistics can reinforce lone ranger
> behavior. People can and should be proud of their work, but why does it
> have to be alone? Working within the context of a team is something to be
> proud of too, but if your stats and standing are graded by how the commits
> and merges land, and counting lines of code, then incentives of the system
> are skewed.
> How do we go about implementing the co-author process? It sounds like
> something worth doing!
>
> On Thu, Jul 12, 2018 at 11:15 AM, Hao Jin  wrote:
>
> > Hi Aaron,
> > To be fair, this discussion has nothing to do with "pride" of SDEs, but
> > rather a discussion on what is a better software engineering practice for
> > the project. Breaking a large project into smaller tasks is a good
> software
> > engineering practice. This article(https://arxiv.org/pdf/1702.01715.pdf)
> > on
> > Google's software engineering practice says: "Engineers are encouraged to
> > keep each individual change small​, with larger changes preferably broken
> > into a series of smaller changes that a reviewer can easily review in one
> > go.". If you have concerns or your comments on this practice, we can take
> > the discussion offline. On the other hand, an important spirit of Apache
> > community is that "one must interact with others, and share vision and
> > knowledge"(https://community.apache.org/contributors/), if you observed
> > that a majority of the contributors have serious problems with their
> > writing maybe you can share some tips and hints on how to write better
> > documentations, in that way not only a lot of us within the community can
> > have some growth but also you can save some time for writing more good
> > documentations and blogposts for MXNet, don't you think so? Or, if you
> only
> > have to fix the doc for someone once in a while, I definitely agree that
> > you should be given the credit for that, and that's where the co-author
> > field can be useful, which was exactly what I was saying in my previous
> > email. Thanks!
> > Hao
> >
> > On Thu, Jul 12, 2018 at 8:16 AM, Aaron Markham <
> aaron.s.mark...@gmail.com>
> > wrote:
> >
> > >  This is a great discussion, and close to my heart, because I want to
> > > include more writers and editors in our community, and I'm struggling
> to
> > > see how to best manage this. It seems like being the sole contributor
> on
> > a
> > > feature is like an engineer's Lone Ranger badge of pride! I feel like
> it
> > > should be a red flag.
> > >
> > > I work in collaboration with dozens of engineers to improve their
> > > documentation, explain their features, change flows to improve user
> > > experience, and sometimes fix bugs and write code. When the PR's docs
> has
> > > great coverage, is clear, and not loaded with bad grammar and spelling
> > > mistakes, I will put comments in a review. But sometimes there needs to
> > be
> > > a complete rework such that hundreds of review comments isn't feasible,
> > and
> > > they can't be properly addressed. In a lot of these cases, I commit my
> > > changes to someone else's fork. Now I know the people I work with on
> > their
> > > PRs appreciate my help, but when all of this work gets squashed down to
> > one
> > > commit, I'm pretty much regularly getting squashed out. I'm not sure
> who
> > > else is in this boat, but does the community recognize our
> contributions
> > > when this is the general mode of operation?
> > >
> > > Regarding co-author - I'm not sure how people would feel about me
> being a
> > > co-author on their work. Documentation and clarity in your work product
> > is
> > > important, but people's views on their personal *code* contribution
> seems
> > > to be more important than the overall code & feature quality itself
> when
> > > docs are part of the package. I feel that if I do follow-on PRs instead
> > of
> > > fixing things before they are merged, that we would be releasing
> > incorrect,
> > > incomplete, and inferior product. But, in absence of a better solution,
> > > maybe that's the pill we have to swallow.
> > >
> > > -1 on lots of small PRs (until we expand our range of committers and
> > reduce
> > > the latency in reviews and merges).
> > > +1 on improving the quality of commit messages, so we don't have to
> > squash
> > > & merge all of the time.
> > > +1 on improving the practic

Re: [DISCUSS] Subscribe dev@ to Github Activities?

[Tianqi Chen]

+1

On Thu, Jul 12, 2018 at 11:10 AM, Sheng Zha  wrote:

> Hi all,
>
> Should we subscribe dev list to github updates on mxnet repo? Both github
> issues/PRs and the dev list are intended for technical discussions and in
> that aspect largely share the same goal. Since MXNet has most activity
> github, this could help dev@ to become more active. Some pros and cons:
>
> Pros:
> - There have been many high quality discussions that happen on github to
> which the dev list can benefit.
> - Replies on update emails are reflected on the specific issue/PR.
> - Users can also choose to click on the link and go to github to
> participate in discussion.
> - We still have the ability to carry out dev@ only conversation.
>
> Cons:
> - Higher volume on dev list.
> - Some discussions might not be suitable for dev@. (though I can't think
> of
> why such conversation should happen on github either)
>
> -sz
>

Re: [DISCUSS] Subscribe dev@ to Github Activities?

[Piyush Ghai]

+1 
> On Jul 12, 2018, at 11:50 AM, Tianqi Chen  wrote:
> 
> +1
> 
> On Thu, Jul 12, 2018 at 11:10 AM, Sheng Zha  wrote:
> 
>> Hi all,
>> 
>> Should we subscribe dev list to github updates on mxnet repo? Both github
>> issues/PRs and the dev list are intended for technical discussions and in
>> that aspect largely share the same goal. Since MXNet has most activity
>> github, this could help dev@ to become more active. Some pros and cons:
>> 
>> Pros:
>> - There have been many high quality discussions that happen on github to
>> which the dev list can benefit.
>> - Replies on update emails are reflected on the specific issue/PR.
>> - Users can also choose to click on the link and go to github to
>> participate in discussion.
>> - We still have the ability to carry out dev@ only conversation.
>> 
>> Cons:
>> - Higher volume on dev list.
>> - Some discussions might not be suitable for dev@. (though I can't think
>> of
>> why such conversation should happen on github either)
>> 
>> -sz
>> 

Re: [DISCUSS] Subscribe dev@ to Github Activities?

[Anirudh Acharya]

+1

On Thu, Jul 12, 2018 at 11:51 AM Piyush Ghai  wrote:

> +1
> > On Jul 12, 2018, at 11:50 AM, Tianqi Chen 
> wrote:
> >
> > +1
> >
> > On Thu, Jul 12, 2018 at 11:10 AM, Sheng Zha  wrote:
> >
> >> Hi all,
> >>
> >> Should we subscribe dev list to github updates on mxnet repo? Both
> github
> >> issues/PRs and the dev list are intended for technical discussions and
> in
> >> that aspect largely share the same goal. Since MXNet has most activity
> >> github, this could help dev@ to become more active. Some pros and cons:
> >>
> >> Pros:
> >> - There have been many high quality discussions that happen on github to
> >> which the dev list can benefit.
> >> - Replies on update emails are reflected on the specific issue/PR.
> >> - Users can also choose to click on the link and go to github to
> >> participate in discussion.
> >> - We still have the ability to carry out dev@ only conversation.
> >>
> >> Cons:
> >> - Higher volume on dev list.
> >> - Some discussions might not be suitable for dev@. (though I can't
> think
> >> of
> >> why such conversation should happen on github either)
> >>
> >> -sz
> >>
>
>

Re: [VOTE] Release MXNet version 1.2.1.RC1

[Zhi Zhang]

On 2018/07/12 17:26:33, Jun Wu  wrote: 
> +1 Built from source and ran the gpu unit tests.
> 
> On Thu, Jul 12, 2018 at 8:01 AM sandeep krishnamurthy <
> sandeep.krishn...@gmail.com> wrote:
> 
> > +1
> >
> > Built from source. Tested on CPU and GPU with Keras-MXNet (ResNet and LSTM
> > examples), works as expected.
> >
> > Best,
> > Sandeep
> >
> > On Thu, Jul 12, 2018 at 7:10 AM Indhu  wrote:
> >
> > > +1
> > >
> > > Built from source. Tested few RNN samples on GPU. Works fine.
> > >
> > > On Thu, Jul 12, 2018, 12:01 AM Haibin Lin 
> > > wrote:
> > >
> > > > +1
> > > > Built from source with cuda and dist kvstore. Ran dist_sync_kvstore.py
> > > > nightly test and it passed.
> > > >
> > > > Best,
> > > > Haibin
> > > >
> > > > On Wed, Jul 11, 2018 at 6:13 PM, Roshani Nagmote <
> > > > roshaninagmo...@gmail.com>
> > > > wrote:
> > > >
> > > > > Hi All,
> > > > >
> > > > > Could you please test and vote for this release? Voting will end
> > > tomorrow
> > > > > by 5:50 pm PDT.
> > > > >
> > > > > Thanks,
> > > > > Roshani
> > > > >
> > > > > On Mon, Jul 9, 2018 at 4:53 PM Roshani Nagmote <
> > > > roshaninagmo...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > I would like to propose a vote to release Apache MXNet (incubating)
> > > > > > version
> > > > > > 1.2.1.RC1. Voting will start now (Monday, Jul 9th) and end at 5:50
> > PM
> > > > > > PDT, Thursday, July 12th.
> > > > > >
> > > > > > Link to release candidate 1.2.1.rc1:
> > > > > > *https://github.com/apache/incubator-mxnet/releases/tag/1.2.1.rc1
> > > > > >  > >*
> > > > > >
> > > > > > View this page, click on "Build from Source", and use the source
> > code
> > > > > > obtained from 1.2.1.rc1 tag:
> > > > > > https://mxnet.incubator.apache.org/install/index.html
> > > > > >
> > > > > > (Note: The README.md points to the 1.2.1 tag and does not work at
> > the
> > > > > > moment.)
> > > > > >
> > > > > > Please remember to test first before voting accordingly:
> > > > > >
> > > > > > +1 = approve
> > > > > > +0 = no opinion
> > > > > > -1 = disapprove (provide reason)
> > > > > >
> > > > > > Thanks,
> > > > > > Roshani
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> > --
> > Sandeep Krishnamurthy
> >
>  + 1 built from source, passed unittest, passed 
> net.save_param/save_parameters/load_param/load_parameters

Re: [VOTE] Release MXNet version 1.2.1.RC1

[Naveen Swamy]

+1

tested Scala build from source and ran scalatest

On Thu, Jul 12, 2018 at 1:53 PM, Zhi Zhang  wrote:

>
>
> On 2018/07/12 17:26:33, Jun Wu  wrote:
> > +1 Built from source and ran the gpu unit tests.
> >
> > On Thu, Jul 12, 2018 at 8:01 AM sandeep krishnamurthy <
> > sandeep.krishn...@gmail.com> wrote:
> >
> > > +1
> > >
> > > Built from source. Tested on CPU and GPU with Keras-MXNet (ResNet and
> LSTM
> > > examples), works as expected.
> > >
> > > Best,
> > > Sandeep
> > >
> > > On Thu, Jul 12, 2018 at 7:10 AM Indhu  wrote:
> > >
> > > > +1
> > > >
> > > > Built from source. Tested few RNN samples on GPU. Works fine.
> > > >
> > > > On Thu, Jul 12, 2018, 12:01 AM Haibin Lin 
> > > > wrote:
> > > >
> > > > > +1
> > > > > Built from source with cuda and dist kvstore. Ran
> dist_sync_kvstore.py
> > > > > nightly test and it passed.
> > > > >
> > > > > Best,
> > > > > Haibin
> > > > >
> > > > > On Wed, Jul 11, 2018 at 6:13 PM, Roshani Nagmote <
> > > > > roshaninagmo...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Hi All,
> > > > > >
> > > > > > Could you please test and vote for this release? Voting will end
> > > > tomorrow
> > > > > > by 5:50 pm PDT.
> > > > > >
> > > > > > Thanks,
> > > > > > Roshani
> > > > > >
> > > > > > On Mon, Jul 9, 2018 at 4:53 PM Roshani Nagmote <
> > > > > roshaninagmo...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Hi all,
> > > > > > >
> > > > > > > I would like to propose a vote to release Apache MXNet
> (incubating)
> > > > > > > version
> > > > > > > 1.2.1.RC1. Voting will start now (Monday, Jul 9th) and end at
> 5:50
> > > PM
> > > > > > > PDT, Thursday, July 12th.
> > > > > > >
> > > > > > > Link to release candidate 1.2.1.rc1:
> > > > > > > *https://github.com/apache/incubator-mxnet/releases/tag/
> 1.2.1.rc1
> > > > > > >  1.2.1.rc1
> > > >*
> > > > > > >
> > > > > > > View this page, click on "Build from Source", and use the
> source
> > > code
> > > > > > > obtained from 1.2.1.rc1 tag:
> > > > > > > https://mxnet.incubator.apache.org/install/index.html
> > > > > > >
> > > > > > > (Note: The README.md points to the 1.2.1 tag and does not work
> at
> > > the
> > > > > > > moment.)
> > > > > > >
> > > > > > > Please remember to test first before voting accordingly:
> > > > > > >
> > > > > > > +1 = approve
> > > > > > > +0 = no opinion
> > > > > > > -1 = disapprove (provide reason)
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Roshani
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > Sandeep Krishnamurthy
> > >
> >  + 1 built from source, passed unittest, passed net.save_param/save_
> parameters/load_param/load_parameters
>

Re: [VOTE] Release MXNet version 1.2.1.RC1

[Lin Yuan]

+1 Built on Windows server. Ran unittests. Works as expected.

On Thu, Jul 12, 2018 at 8:01 AM sandeep krishnamurthy <
sandeep.krishn...@gmail.com> wrote:

> +1
>
> Built from source. Tested on CPU and GPU with Keras-MXNet (ResNet and LSTM
> examples), works as expected.
>
> Best,
> Sandeep
>
> On Thu, Jul 12, 2018 at 7:10 AM Indhu  wrote:
>
> > +1
> >
> > Built from source. Tested few RNN samples on GPU. Works fine.
> >
> > On Thu, Jul 12, 2018, 12:01 AM Haibin Lin 
> > wrote:
> >
> > > +1
> > > Built from source with cuda and dist kvstore. Ran dist_sync_kvstore.py
> > > nightly test and it passed.
> > >
> > > Best,
> > > Haibin
> > >
> > > On Wed, Jul 11, 2018 at 6:13 PM, Roshani Nagmote <
> > > roshaninagmo...@gmail.com>
> > > wrote:
> > >
> > > > Hi All,
> > > >
> > > > Could you please test and vote for this release? Voting will end
> > tomorrow
> > > > by 5:50 pm PDT.
> > > >
> > > > Thanks,
> > > > Roshani
> > > >
> > > > On Mon, Jul 9, 2018 at 4:53 PM Roshani Nagmote <
> > > roshaninagmo...@gmail.com>
> > > > wrote:
> > > >
> > > > > Hi all,
> > > > >
> > > > > I would like to propose a vote to release Apache MXNet (incubating)
> > > > > version
> > > > > 1.2.1.RC1. Voting will start now (Monday, Jul 9th) and end at 5:50
> PM
> > > > > PDT, Thursday, July 12th.
> > > > >
> > > > > Link to release candidate 1.2.1.rc1:
> > > > > *https://github.com/apache/incubator-mxnet/releases/tag/1.2.1.rc1
> > > > >  >*
> > > > >
> > > > > View this page, click on "Build from Source", and use the source
> code
> > > > > obtained from 1.2.1.rc1 tag:
> > > > > https://mxnet.incubator.apache.org/install/index.html
> > > > >
> > > > > (Note: The README.md points to the 1.2.1 tag and does not work at
> the
> > > > > moment.)
> > > > >
> > > > > Please remember to test first before voting accordingly:
> > > > >
> > > > > +1 = approve
> > > > > +0 = no opinion
> > > > > -1 = disapprove (provide reason)
> > > > >
> > > > > Thanks,
> > > > > Roshani
> > > > >
> > > >
> > >
> >
>
>
> --
> Sandeep Krishnamurthy
>

Re: [DISCUSS] Subscribe dev@ to Github Activities?

[Lin Yuan]

+1

On Thu, Jul 12, 2018 at 12:26 PM Anirudh Acharya 
wrote:

> +1
>
> On Thu, Jul 12, 2018 at 11:51 AM Piyush Ghai 
> wrote:
>
> > +1
> > > On Jul 12, 2018, at 11:50 AM, Tianqi Chen 
> > wrote:
> > >
> > > +1
> > >
> > > On Thu, Jul 12, 2018 at 11:10 AM, Sheng Zha 
> wrote:
> > >
> > >> Hi all,
> > >>
> > >> Should we subscribe dev list to github updates on mxnet repo? Both
> > github
> > >> issues/PRs and the dev list are intended for technical discussions and
> > in
> > >> that aspect largely share the same goal. Since MXNet has most activity
> > >> github, this could help dev@ to become more active. Some pros and
> cons:
> > >>
> > >> Pros:
> > >> - There have been many high quality discussions that happen on github
> to
> > >> which the dev list can benefit.
> > >> - Replies on update emails are reflected on the specific issue/PR.
> > >> - Users can also choose to click on the link and go to github to
> > >> participate in discussion.
> > >> - We still have the ability to carry out dev@ only conversation.
> > >>
> > >> Cons:
> > >> - Higher volume on dev list.
> > >> - Some discussions might not be suitable for dev@. (though I can't
> > think
> > >> of
> > >> why such conversation should happen on github either)
> > >>
> > >> -sz
> > >>
> >
> >
>

Re: Squash/Merge PRs

[Naveen Swamy]

@Aaron, I do not think most contributors(SDE or not) were even aware that
their commits are getting squashed into one and thereby others losing
credit on that work. I would assume no bad intentions there.

@Hao,
Agree to breaking down into small and reasonable sized PRs, but I think
very small PRs will overwhelm the CI as it stands since it runs
everything(this is a separate topic and needs fixing).

For cases similar to Aaron's he can raise the PR for the doc
work(regardless of fork or not) and add other contributors as co-authors.

@Marco, co-author might not be suitable always suitable and agree with Hao
that should be used on exceptions. co-author also makes it hard to see the
contributions individually.

@Marco, why can we not have Rebase merge enabled on the repo and use that
when there are multiple contributors. This discussion is only about Not
Squashing when there are multiple contributors and agree to continue the
practice of Squashing in general.

Until the tooling is fixed, I suggest to use the co-author feature when
collaborating on a fork.

Also, I just want to reiterate and request contributors to have meaningful
and fewer commits on PRs.

Thanks, Naveen


On Thu, Jul 12, 2018 at 11:40 AM, Marco de Abreu <
marco.g.ab...@googlemail.com.invalid> wrote:

> As of now it will require the usage of a merge bot as far as I understand
> this issue: https://github.com/python/miss-islington/issues/16. Instead of
> using the web interface do merge, we'd then trigger the bot to do the merge
> on our behalf. There are pre-made solutions on the internet we might be
> able to leverage, but it would take some time to get into it and adapt our
> process.
>
> Additionally, GitHub has this feature request tracked internally. Let's see
> when they get to add it.
>
> -Marco
>
>
>
> Aaron Markham  schrieb am Do., 12. Juli 2018,
> 21:33:
>
> > My point was about collaboration, or the lack thereof, and how the
> tooling
> > and apparent rewards from contribution statistics can reinforce lone
> ranger
> > behavior. People can and should be proud of their work, but why does it
> > have to be alone? Working within the context of a team is something to be
> > proud of too, but if your stats and standing are graded by how the
> commits
> > and merges land, and counting lines of code, then incentives of the
> system
> > are skewed.
> > How do we go about implementing the co-author process? It sounds like
> > something worth doing!
> >
> > On Thu, Jul 12, 2018 at 11:15 AM, Hao Jin  wrote:
> >
> > > Hi Aaron,
> > > To be fair, this discussion has nothing to do with "pride" of SDEs, but
> > > rather a discussion on what is a better software engineering practice
> for
> > > the project. Breaking a large project into smaller tasks is a good
> > software
> > > engineering practice. This article(https://arxiv.org/pdf/
> 1702.01715.pdf)
> > > on
> > > Google's software engineering practice says: "Engineers are encouraged
> to
> > > keep each individual change small​, with larger changes preferably
> broken
> > > into a series of smaller changes that a reviewer can easily review in
> one
> > > go.". If you have concerns or your comments on this practice, we can
> take
> > > the discussion offline. On the other hand, an important spirit of
> Apache
> > > community is that "one must interact with others, and share vision and
> > > knowledge"(https://community.apache.org/contributors/), if you
> observed
> > > that a majority of the contributors have serious problems with their
> > > writing maybe you can share some tips and hints on how to write better
> > > documentations, in that way not only a lot of us within the community
> can
> > > have some growth but also you can save some time for writing more good
> > > documentations and blogposts for MXNet, don't you think so? Or, if you
> > only
> > > have to fix the doc for someone once in a while, I definitely agree
> that
> > > you should be given the credit for that, and that's where the co-author
> > > field can be useful, which was exactly what I was saying in my previous
> > > email. Thanks!
> > > Hao
> > >
> > > On Thu, Jul 12, 2018 at 8:16 AM, Aaron Markham <
> > aaron.s.mark...@gmail.com>
> > > wrote:
> > >
> > > >  This is a great discussion, and close to my heart, because I want to
> > > > include more writers and editors in our community, and I'm struggling
> > to
> > > > see how to best manage this. It seems like being the sole contributor
> > on
> > > a
> > > > feature is like an engineer's Lone Ranger badge of pride! I feel like
> > it
> > > > should be a red flag.
> > > >
> > > > I work in collaboration with dozens of engineers to improve their
> > > > documentation, explain their features, change flows to improve user
> > > > experience, and sometimes fix bugs and write code. When the PR's docs
> > has
> > > > great coverage, is clear, and not loaded with bad grammar and
> spelling
> > > > mistakes, I will put comments in a review. But sometimes there needs
> to
> > >

Deprecate python 2

[Pedro Larroy]

Hi

I would like to know your opinion in regards to deprecating and removing
Python 2. Maybe for MXNet 2.0 ?

What's the reason to have support for Python2?

Pedro.

Re: Deprecate python 2

[Tianqi Chen]

I think we just need to be on side with the community. Most community plans
to deprecate python2 at beginning of 2019 and drop support at 2020

Tianqi

On Thu, Jul 12, 2018 at 2:51 PM, Pedro Larroy 
wrote:

> Hi
>
> I would like to know your opinion in regards to deprecating and removing
> Python 2. Maybe for MXNet 2.0 ?
>
> What's the reason to have support for Python2?
>
> Pedro.
>

Re: Deprecate python 2

[Marco de Abreu]

CentOS 7, for example, does not offer stable Python 3 support. We're using
an unstable version in our CI to verify it none the less. I think that's a
hard stop for quite a few users.

-Marco

Pedro Larroy  schrieb am Do., 12. Juli 2018,
23:51:

> Hi
>
> I would like to know your opinion in regards to deprecating and removing
> Python 2. Maybe for MXNet 2.0 ?
>
> What's the reason to have support for Python2?
>
> Pedro.
>

Re: Deprecate python 2

[Tianqi Chen]

FYI https://python3statement.org/

On Thu, Jul 12, 2018 at 3:00 PM, Marco de Abreu <
marco.g.ab...@googlemail.com.invalid> wrote:

> CentOS 7, for example, does not offer stable Python 3 support. We're using
> an unstable version in our CI to verify it none the less. I think that's a
> hard stop for quite a few users.
>
> -Marco
>
> Pedro Larroy  schrieb am Do., 12. Juli 2018,
> 23:51:
>
> > Hi
> >
> > I would like to know your opinion in regards to deprecating and removing
> > Python 2. Maybe for MXNet 2.0 ?
> >
> > What's the reason to have support for Python2?
> >
> > Pedro.
> >
>

Re: Squash/Merge PRs

[Pedro Larroy]

This is a great discussion, thanks for raising the question Naveen.

>From my experience working in all kinds of software project of varying
sizes and flavours:

   1. People should be aware of git rebase interactive and have more
   hygiene in their PRs. If a PR is hygienic and is separated in a set of
   semantic commits, it's better not squashed as it helps finding bugs /
   bisecting. A "dirty" PR with WIP commits, is better squashed, or requested
   to rebase interactively on CR.
   2. Mixing different semantic changes on a single PR is an anti-pattern,
   for example fixing whitespace or reformatting many lines and changing some
   code which is hidden in a bunch of trivial changes and could cause a bug or
   major change of behaviour.
   3. Agreed what with others have mentioned about small incremental steps
   better than huge PRs. We also have JIRA or issues to relate a set of PRs
   together. If not possible, PR with a set of non squashed commits is also
   good.

Hope it helps.

Pedro.

On Thu, Jul 12, 2018 at 11:47 PM Naveen Swamy  wrote:

> @Aaron, I do not think most contributors(SDE or not) were even aware that
> their commits are getting squashed into one and thereby others losing
> credit on that work. I would assume no bad intentions there.
>
> @Hao,
> Agree to breaking down into small and reasonable sized PRs, but I think
> very small PRs will overwhelm the CI as it stands since it runs
> everything(this is a separate topic and needs fixing).
>
> For cases similar to Aaron's he can raise the PR for the doc
> work(regardless of fork or not) and add other contributors as co-authors.
>
> @Marco, co-author might not be suitable always suitable and agree with Hao
> that should be used on exceptions. co-author also makes it hard to see the
> contributions individually.
>
> @Marco, why can we not have Rebase merge enabled on the repo and use that
> when there are multiple contributors. This discussion is only about Not
> Squashing when there are multiple contributors and agree to continue the
> practice of Squashing in general.
>
> Until the tooling is fixed, I suggest to use the co-author feature when
> collaborating on a fork.
>
> Also, I just want to reiterate and request contributors to have meaningful
> and fewer commits on PRs.
>
> Thanks, Naveen
>
>
> On Thu, Jul 12, 2018 at 11:40 AM, Marco de Abreu <
> marco.g.ab...@googlemail.com.invalid> wrote:
>
> > As of now it will require the usage of a merge bot as far as I understand
> > this issue: https://github.com/python/miss-islington/issues/16. Instead
> of
> > using the web interface do merge, we'd then trigger the bot to do the
> merge
> > on our behalf. There are pre-made solutions on the internet we might be
> > able to leverage, but it would take some time to get into it and adapt
> our
> > process.
> >
> > Additionally, GitHub has this feature request tracked internally. Let's
> see
> > when they get to add it.
> >
> > -Marco
> >
> >
> >
> > Aaron Markham  schrieb am Do., 12. Juli 2018,
> > 21:33:
> >
> > > My point was about collaboration, or the lack thereof, and how the
> > tooling
> > > and apparent rewards from contribution statistics can reinforce lone
> > ranger
> > > behavior. People can and should be proud of their work, but why does it
> > > have to be alone? Working within the context of a team is something to
> be
> > > proud of too, but if your stats and standing are graded by how the
> > commits
> > > and merges land, and counting lines of code, then incentives of the
> > system
> > > are skewed.
> > > How do we go about implementing the co-author process? It sounds like
> > > something worth doing!
> > >
> > > On Thu, Jul 12, 2018 at 11:15 AM, Hao Jin  wrote:
> > >
> > > > Hi Aaron,
> > > > To be fair, this discussion has nothing to do with "pride" of SDEs,
> but
> > > > rather a discussion on what is a better software engineering practice
> > for
> > > > the project. Breaking a large project into smaller tasks is a good
> > > software
> > > > engineering practice. This article(https://arxiv.org/pdf/
> > 1702.01715.pdf)
> > > > on
> > > > Google's software engineering practice says: "Engineers are
> encouraged
> > to
> > > > keep each individual change small​, with larger changes preferably
> > broken
> > > > into a series of smaller changes that a reviewer can easily review in
> > one
> > > > go.". If you have concerns or your comments on this practice, we can
> > take
> > > > the discussion offline. On the other hand, an important spirit of
> > Apache
> > > > community is that "one must interact with others, and share vision
> and
> > > > knowledge"(https://community.apache.org/contributors/), if you
> > observed
> > > > that a majority of the contributors have serious problems with their
> > > > writing maybe you can share some tips and hints on how to write
> better
> > > > documentations, in that way not only a lot of us within the community
> > can
> > > > have some growth but also you can save some time for writ

Re: [VOTE] Release MXNet version 1.2.1.RC1

[Sergio Fernández]

+1 (binding)

On Mon, Jul 9, 2018, 16:53 Roshani Nagmote 
wrote:

> Hi all,
>
> I would like to propose a vote to release Apache MXNet (incubating) version
> 1.2.1.RC1. Voting will start now (Monday, Jul 9th) and end at 5:50 PM
> PDT, Thursday, July 12th.
>
> Link to release candidate 1.2.1.rc1:
> *https://github.com/apache/incubator-mxnet/releases/tag/1.2.1.rc1
> *
>
> View this page, click on "Build from Source", and use the source code
> obtained from 1.2.1.rc1 tag:
> https://mxnet.incubator.apache.org/install/index.html
>
> (Note: The README.md points to the 1.2.1 tag and does not work at the
> moment.)
>
> Please remember to test first before voting accordingly:
>
> +1 = approve
> +0 = no opinion
> -1 = disapprove (provide reason)
>
> Thanks,
> Roshani
>

Re: [DISCUSS] Subscribe dev@ to Github Activities?

[Pedro Larroy]

-1   It's a lot of traffic, whomever wants to subscribe can do it in
github. I'm afraid it will decrease signal to noise ratio in the list.

On Thu, Jul 12, 2018 at 11:32 PM Lin Yuan  wrote:

> +1
>
> On Thu, Jul 12, 2018 at 12:26 PM Anirudh Acharya 
> wrote:
>
> > +1
> >
> > On Thu, Jul 12, 2018 at 11:51 AM Piyush Ghai 
> > wrote:
> >
> > > +1
> > > > On Jul 12, 2018, at 11:50 AM, Tianqi Chen 
> > > wrote:
> > > >
> > > > +1
> > > >
> > > > On Thu, Jul 12, 2018 at 11:10 AM, Sheng Zha 
> > wrote:
> > > >
> > > >> Hi all,
> > > >>
> > > >> Should we subscribe dev list to github updates on mxnet repo? Both
> > > github
> > > >> issues/PRs and the dev list are intended for technical discussions
> and
> > > in
> > > >> that aspect largely share the same goal. Since MXNet has most
> activity
> > > >> github, this could help dev@ to become more active. Some pros and
> > cons:
> > > >>
> > > >> Pros:
> > > >> - There have been many high quality discussions that happen on
> github
> > to
> > > >> which the dev list can benefit.
> > > >> - Replies on update emails are reflected on the specific issue/PR.
> > > >> - Users can also choose to click on the link and go to github to
> > > >> participate in discussion.
> > > >> - We still have the ability to carry out dev@ only conversation.
> > > >>
> > > >> Cons:
> > > >> - Higher volume on dev list.
> > > >> - Some discussions might not be suitable for dev@. (though I can't
> > > think
> > > >> of
> > > >> why such conversation should happen on github either)
> > > >>
> > > >> -sz
> > > >>
> > >
> > >
> >
>

Re: [DISCUSS] Subscribe dev@ to Github Activities?

[Qing Lan]

+0.5
Is there a @dev-apache option we can have? 
So we can decide whether to share the discussion on this mailing list.

Thanks,
Qing

On 7/12/18, 3:08 PM, "Pedro Larroy"  wrote:

-1   It's a lot of traffic, whomever wants to subscribe can do it in
github. I'm afraid it will decrease signal to noise ratio in the list.

On Thu, Jul 12, 2018 at 11:32 PM Lin Yuan  wrote:

> +1
>
> On Thu, Jul 12, 2018 at 12:26 PM Anirudh Acharya 
> wrote:
>
> > +1
> >
> > On Thu, Jul 12, 2018 at 11:51 AM Piyush Ghai 
> > wrote:
> >
> > > +1
> > > > On Jul 12, 2018, at 11:50 AM, Tianqi Chen 
> > > wrote:
> > > >
> > > > +1
> > > >
> > > > On Thu, Jul 12, 2018 at 11:10 AM, Sheng Zha 
> > wrote:
> > > >
> > > >> Hi all,
> > > >>
> > > >> Should we subscribe dev list to github updates on mxnet repo? Both
> > > github
> > > >> issues/PRs and the dev list are intended for technical discussions
> and
> > > in
> > > >> that aspect largely share the same goal. Since MXNet has most
> activity
> > > >> github, this could help dev@ to become more active. Some pros and
> > cons:
> > > >>
> > > >> Pros:
> > > >> - There have been many high quality discussions that happen on
> github
> > to
> > > >> which the dev list can benefit.
> > > >> - Replies on update emails are reflected on the specific issue/PR.
> > > >> - Users can also choose to click on the link and go to github to
> > > >> participate in discussion.
> > > >> - We still have the ability to carry out dev@ only conversation.
> > > >>
> > > >> Cons:
> > > >> - Higher volume on dev list.
> > > >> - Some discussions might not be suitable for dev@. (though I can't
> > > think
> > > >> of
> > > >> why such conversation should happen on github either)
> > > >>
> > > >> -sz
> > > >>
> > >
> > >
> >
>

Re: [DISCUSS] Subscribe dev@ to Github Activities?

[Haibin Lin]

I'm a bit concerned with the amount of emails flooding in. In the past week
there're 32 new issues and 35 new pull requests. This means on avg 10 email
per day and I doubt I'll read all of them.. Does the Spark community
subscribe dev@ to github?

Best,
Haibin

On Thu, Jul 12, 2018 at 3:08 PM, Pedro Larroy 
wrote:

> -1   It's a lot of traffic, whomever wants to subscribe can do it in
> github. I'm afraid it will decrease signal to noise ratio in the list.
>
> On Thu, Jul 12, 2018 at 11:32 PM Lin Yuan  wrote:
>
> > +1
> >
> > On Thu, Jul 12, 2018 at 12:26 PM Anirudh Acharya 
> > wrote:
> >
> > > +1
> > >
> > > On Thu, Jul 12, 2018 at 11:51 AM Piyush Ghai 
> > > wrote:
> > >
> > > > +1
> > > > > On Jul 12, 2018, at 11:50 AM, Tianqi Chen <
> tqc...@cs.washington.edu>
> > > > wrote:
> > > > >
> > > > > +1
> > > > >
> > > > > On Thu, Jul 12, 2018 at 11:10 AM, Sheng Zha 
> > > wrote:
> > > > >
> > > > >> Hi all,
> > > > >>
> > > > >> Should we subscribe dev list to github updates on mxnet repo? Both
> > > > github
> > > > >> issues/PRs and the dev list are intended for technical discussions
> > and
> > > > in
> > > > >> that aspect largely share the same goal. Since MXNet has most
> > activity
> > > > >> github, this could help dev@ to become more active. Some pros and
> > > cons:
> > > > >>
> > > > >> Pros:
> > > > >> - There have been many high quality discussions that happen on
> > github
> > > to
> > > > >> which the dev list can benefit.
> > > > >> - Replies on update emails are reflected on the specific issue/PR.
> > > > >> - Users can also choose to click on the link and go to github to
> > > > >> participate in discussion.
> > > > >> - We still have the ability to carry out dev@ only conversation.
> > > > >>
> > > > >> Cons:
> > > > >> - Higher volume on dev list.
> > > > >> - Some discussions might not be suitable for dev@. (though I
> can't
> > > > think
> > > > >> of
> > > > >> why such conversation should happen on github either)
> > > > >>
> > > > >> -sz
> > > > >>
> > > >
> > > >
> > >
> >
>

答复: Deprecate python 2

[Chen HY]

CentOS 7 has Python 3.4.8 and python 3.6.3 in epel repo.
Is that stable ?
HY
发件人: Marco de Abreu
发送时间: 2018年7月12日 23:00
收件人: dev@mxnet.incubator.apache.org
主题: Re: Deprecate python 2

CentOS 7, for example, does not offer stable Python 3 support. We're using
an unstable version in our CI to verify it none the less. I think that's a
hard stop for quite a few users.

-Marco

Pedro Larroy  schrieb am Do., 12. Juli 2018,
23:51:

> Hi
>
> I would like to know your opinion in regards to deprecating and removing
> Python 2. Maybe for MXNet 2.0 ?
>
> What's the reason to have support for Python2?
>
> Pedro.
>

Re: [DISCUSS] Subscribe dev@ to Github Activities?

[Timur Shenkao]

Flink - yes
Spark - it was previously but not now

Yeah, amount of messages would be tripled at least: Jira + Github issue + PR

On Thu, Jul 12, 2018 at 11:13 PM, Haibin Lin 
wrote:

> I'm a bit concerned with the amount of emails flooding in. In the past week
> there're 32 new issues and 35 new pull requests. This means on avg 10 email
> per day and I doubt I'll read all of them.. Does the Spark community
> subscribe dev@ to github?
>
> Best,
> Haibin
>
> On Thu, Jul 12, 2018 at 3:08 PM, Pedro Larroy <
> pedro.larroy.li...@gmail.com>
> wrote:
>
> > -1   It's a lot of traffic, whomever wants to subscribe can do it in
> > github. I'm afraid it will decrease signal to noise ratio in the list.
> >
> > On Thu, Jul 12, 2018 at 11:32 PM Lin Yuan  wrote:
> >
> > > +1
> > >
> > > On Thu, Jul 12, 2018 at 12:26 PM Anirudh Acharya <
> anirudhk...@gmail.com>
> > > wrote:
> > >
> > > > +1
> > > >
> > > > On Thu, Jul 12, 2018 at 11:51 AM Piyush Ghai 
> > > > wrote:
> > > >
> > > > > +1
> > > > > > On Jul 12, 2018, at 11:50 AM, Tianqi Chen <
> > tqc...@cs.washington.edu>
> > > > > wrote:
> > > > > >
> > > > > > +1
> > > > > >
> > > > > > On Thu, Jul 12, 2018 at 11:10 AM, Sheng Zha 
> > > > wrote:
> > > > > >
> > > > > >> Hi all,
> > > > > >>
> > > > > >> Should we subscribe dev list to github updates on mxnet repo?
> Both
> > > > > github
> > > > > >> issues/PRs and the dev list are intended for technical
> discussions
> > > and
> > > > > in
> > > > > >> that aspect largely share the same goal. Since MXNet has most
> > > activity
> > > > > >> github, this could help dev@ to become more active. Some pros
> and
> > > > cons:
> > > > > >>
> > > > > >> Pros:
> > > > > >> - There have been many high quality discussions that happen on
> > > github
> > > > to
> > > > > >> which the dev list can benefit.
> > > > > >> - Replies on update emails are reflected on the specific
> issue/PR.
> > > > > >> - Users can also choose to click on the link and go to github to
> > > > > >> participate in discussion.
> > > > > >> - We still have the ability to carry out dev@ only
> conversation.
> > > > > >>
> > > > > >> Cons:
> > > > > >> - Higher volume on dev list.
> > > > > >> - Some discussions might not be suitable for dev@. (though I
> > can't
> > > > > think
> > > > > >> of
> > > > > >> why such conversation should happen on github either)
> > > > > >>
> > > > > >> -sz
> > > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: Squash/Merge PRs

[Marco de Abreu]

Fully agree, if we can get our commit hygiene up to industry standard, I
don't see any problems in using rebase merge instead. For the short term I
agree that it should be fine to rebase merge individual PRs with multiple
contributors. But in my opinion we should then insist on people amending
their commit history if we deem it below our standard. A PR should not be
rebase merged if the history is not proper - verifying that is the
responsibility of the merging committer, but ideally, we'd make people
aware of problems early on. What do you think?

In general, I think we should gradually start taking this into account when
reviewing with the goal of all PRs having a proper commit history. This
would allow us in the long term to completely move away from squashing.

-Marco

Pedro Larroy  schrieb am Fr., 13. Juli 2018,
00:07:

> This is a great discussion, thanks for raising the question Naveen.
>
> From my experience working in all kinds of software project of varying
> sizes and flavours:
>
>1. People should be aware of git rebase interactive and have more
>hygiene in their PRs. If a PR is hygienic and is separated in a set of
>semantic commits, it's better not squashed as it helps finding bugs /
>bisecting. A "dirty" PR with WIP commits, is better squashed, or
> requested
>to rebase interactively on CR.
>2. Mixing different semantic changes on a single PR is an anti-pattern,
>for example fixing whitespace or reformatting many lines and changing
> some
>code which is hidden in a bunch of trivial changes and could cause a
> bug or
>major change of behaviour.
>3. Agreed what with others have mentioned about small incremental steps
>better than huge PRs. We also have JIRA or issues to relate a set of PRs
>together. If not possible, PR with a set of non squashed commits is also
>good.
>
> Hope it helps.
>
> Pedro.
>
> On Thu, Jul 12, 2018 at 11:47 PM Naveen Swamy  wrote:
>
> > @Aaron, I do not think most contributors(SDE or not) were even aware that
> > their commits are getting squashed into one and thereby others losing
> > credit on that work. I would assume no bad intentions there.
> >
> > @Hao,
> > Agree to breaking down into small and reasonable sized PRs, but I think
> > very small PRs will overwhelm the CI as it stands since it runs
> > everything(this is a separate topic and needs fixing).
> >
> > For cases similar to Aaron's he can raise the PR for the doc
> > work(regardless of fork or not) and add other contributors as co-authors.
> >
> > @Marco, co-author might not be suitable always suitable and agree with
> Hao
> > that should be used on exceptions. co-author also makes it hard to see
> the
> > contributions individually.
> >
> > @Marco, why can we not have Rebase merge enabled on the repo and use that
> > when there are multiple contributors. This discussion is only about Not
> > Squashing when there are multiple contributors and agree to continue the
> > practice of Squashing in general.
> >
> > Until the tooling is fixed, I suggest to use the co-author feature when
> > collaborating on a fork.
> >
> > Also, I just want to reiterate and request contributors to have
> meaningful
> > and fewer commits on PRs.
> >
> > Thanks, Naveen
> >
> >
> > On Thu, Jul 12, 2018 at 11:40 AM, Marco de Abreu <
> > marco.g.ab...@googlemail.com.invalid> wrote:
> >
> > > As of now it will require the usage of a merge bot as far as I
> understand
> > > this issue: https://github.com/python/miss-islington/issues/16.
> Instead
> > of
> > > using the web interface do merge, we'd then trigger the bot to do the
> > merge
> > > on our behalf. There are pre-made solutions on the internet we might be
> > > able to leverage, but it would take some time to get into it and adapt
> > our
> > > process.
> > >
> > > Additionally, GitHub has this feature request tracked internally. Let's
> > see
> > > when they get to add it.
> > >
> > > -Marco
> > >
> > >
> > >
> > > Aaron Markham  schrieb am Do., 12. Juli
> 2018,
> > > 21:33:
> > >
> > > > My point was about collaboration, or the lack thereof, and how the
> > > tooling
> > > > and apparent rewards from contribution statistics can reinforce lone
> > > ranger
> > > > behavior. People can and should be proud of their work, but why does
> it
> > > > have to be alone? Working within the context of a team is something
> to
> > be
> > > > proud of too, but if your stats and standing are graded by how the
> > > commits
> > > > and merges land, and counting lines of code, then incentives of the
> > > system
> > > > are skewed.
> > > > How do we go about implementing the co-author process? It sounds like
> > > > something worth doing!
> > > >
> > > > On Thu, Jul 12, 2018 at 11:15 AM, Hao Jin 
> wrote:
> > > >
> > > > > Hi Aaron,
> > > > > To be fair, this discussion has nothing to do with "pride" of SDEs,
> > but
> > > > > rather a discussion on what is a better software engineering
> practice
> > > for
> > > > > the project. Breaking a 

Re: [VOTE] Release MXNet version 1.2.1.RC1

[Hao Jin]

+1 Built on Ubuntu with CUDA 9.0 and CuDNN 7 and verified that sparse tests
are passing.
Hao

On Thu, Jul 12, 2018 at 3:01 PM, Sergio Fernández  wrote:

> +1 (binding)
>
> On Mon, Jul 9, 2018, 16:53 Roshani Nagmote 
> wrote:
>
> > Hi all,
> >
> > I would like to propose a vote to release Apache MXNet (incubating)
> version
> > 1.2.1.RC1. Voting will start now (Monday, Jul 9th) and end at 5:50 PM
> > PDT, Thursday, July 12th.
> >
> > Link to release candidate 1.2.1.rc1:
> > *https://github.com/apache/incubator-mxnet/releases/tag/1.2.1.rc1
> > *
> >
> > View this page, click on "Build from Source", and use the source code
> > obtained from 1.2.1.rc1 tag:
> > https://mxnet.incubator.apache.org/install/index.html
> >
> > (Note: The README.md points to the 1.2.1 tag and does not work at the
> > moment.)
> >
> > Please remember to test first before voting accordingly:
> >
> > +1 = approve
> > +0 = no opinion
> > -1 = disapprove (provide reason)
> >
> > Thanks,
> > Roshani
> >
>

Re: [DISCUSS] Subscribe dev@ to Github Activities?

[Zha, Sheng]

My intention is really just to bridge the gap between so much happening on 
github v.s. "whatever didn't happen on dev list didn't happen".

Also, since dev@ is intended to be an asynchronous way for community to follow 
technical conversations, there wasn't really a requirement for anyone to read 
all of them in the first place.

Best regards,
-sz

On 7/12/18, 3:20 PM, "Timur Shenkao"  wrote:

Flink - yes
Spark - it was previously but not now

Yeah, amount of messages would be tripled at least: Jira + Github issue + PR

On Thu, Jul 12, 2018 at 11:13 PM, Haibin Lin 
wrote:

> I'm a bit concerned with the amount of emails flooding in. In the past 
week
> there're 32 new issues and 35 new pull requests. This means on avg 10 
email
> per day and I doubt I'll read all of them.. Does the Spark community
> subscribe dev@ to github?
>
> Best,
> Haibin
>
> On Thu, Jul 12, 2018 at 3:08 PM, Pedro Larroy <
> pedro.larroy.li...@gmail.com>
> wrote:
>
> > -1   It's a lot of traffic, whomever wants to subscribe can do it in
> > github. I'm afraid it will decrease signal to noise ratio in the list.
> >
> > On Thu, Jul 12, 2018 at 11:32 PM Lin Yuan  wrote:
> >
> > > +1
> > >
> > > On Thu, Jul 12, 2018 at 12:26 PM Anirudh Acharya <
> anirudhk...@gmail.com>
> > > wrote:
> > >
> > > > +1
> > > >
> > > > On Thu, Jul 12, 2018 at 11:51 AM Piyush Ghai 
> > > > wrote:
> > > >
> > > > > +1
> > > > > > On Jul 12, 2018, at 11:50 AM, Tianqi Chen <
> > tqc...@cs.washington.edu>
> > > > > wrote:
> > > > > >
> > > > > > +1
> > > > > >
> > > > > > On Thu, Jul 12, 2018 at 11:10 AM, Sheng Zha 
> > > > wrote:
> > > > > >
> > > > > >> Hi all,
> > > > > >>
> > > > > >> Should we subscribe dev list to github updates on mxnet repo?
> Both
> > > > > github
> > > > > >> issues/PRs and the dev list are intended for technical
> discussions
> > > and
> > > > > in
> > > > > >> that aspect largely share the same goal. Since MXNet has most
> > > activity
> > > > > >> github, this could help dev@ to become more active. Some pros
> and
> > > > cons:
> > > > > >>
> > > > > >> Pros:
> > > > > >> - There have been many high quality discussions that happen on
> > > github
> > > > to
> > > > > >> which the dev list can benefit.
> > > > > >> - Replies on update emails are reflected on the specific
> issue/PR.
> > > > > >> - Users can also choose to click on the link and go to github 
to
> > > > > >> participate in discussion.
> > > > > >> - We still have the ability to carry out dev@ only
> conversation.
> > > > > >>
> > > > > >> Cons:
> > > > > >> - Higher volume on dev list.
> > > > > >> - Some discussions might not be suitable for dev@. (though I
> > can't
> > > > > think
> > > > > >> of
> > > > > >> why such conversation should happen on github either)
> > > > > >>
> > > > > >> -sz
> > > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] Subscribe dev@ to Github Activities?

[Haibin Lin]

Agree. +1 for more transparency

On Thu, Jul 12, 2018 at 3:27 PM, Zha, Sheng 
wrote:

> My intention is really just to bridge the gap between so much happening on
> github v.s. "whatever didn't happen on dev list didn't happen".
>
> Also, since dev@ is intended to be an asynchronous way for community to
> follow technical conversations, there wasn't really a requirement for
> anyone to read all of them in the first place.
>
> Best regards,
> -sz
>
> On 7/12/18, 3:20 PM, "Timur Shenkao"  wrote:
>
> Flink - yes
> Spark - it was previously but not now
>
> Yeah, amount of messages would be tripled at least: Jira + Github
> issue + PR
>
> On Thu, Jul 12, 2018 at 11:13 PM, Haibin Lin  >
> wrote:
>
> > I'm a bit concerned with the amount of emails flooding in. In the
> past week
> > there're 32 new issues and 35 new pull requests. This means on avg
> 10 email
> > per day and I doubt I'll read all of them.. Does the Spark community
> > subscribe dev@ to github?
> >
> > Best,
> > Haibin
> >
> > On Thu, Jul 12, 2018 at 3:08 PM, Pedro Larroy <
> > pedro.larroy.li...@gmail.com>
> > wrote:
> >
> > > -1   It's a lot of traffic, whomever wants to subscribe can do it
> in
> > > github. I'm afraid it will decrease signal to noise ratio in the
> list.
> > >
> > > On Thu, Jul 12, 2018 at 11:32 PM Lin Yuan 
> wrote:
> > >
> > > > +1
> > > >
> > > > On Thu, Jul 12, 2018 at 12:26 PM Anirudh Acharya <
> > anirudhk...@gmail.com>
> > > > wrote:
> > > >
> > > > > +1
> > > > >
> > > > > On Thu, Jul 12, 2018 at 11:51 AM Piyush Ghai <
> ghai.piy...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > +1
> > > > > > > On Jul 12, 2018, at 11:50 AM, Tianqi Chen <
> > > tqc...@cs.washington.edu>
> > > > > > wrote:
> > > > > > >
> > > > > > > +1
> > > > > > >
> > > > > > > On Thu, Jul 12, 2018 at 11:10 AM, Sheng Zha <
> szha@gmail.com>
> > > > > wrote:
> > > > > > >
> > > > > > >> Hi all,
> > > > > > >>
> > > > > > >> Should we subscribe dev list to github updates on mxnet
> repo?
> > Both
> > > > > > github
> > > > > > >> issues/PRs and the dev list are intended for technical
> > discussions
> > > > and
> > > > > > in
> > > > > > >> that aspect largely share the same goal. Since MXNet has
> most
> > > > activity
> > > > > > >> github, this could help dev@ to become more active. Some
> pros
> > and
> > > > > cons:
> > > > > > >>
> > > > > > >> Pros:
> > > > > > >> - There have been many high quality discussions that
> happen on
> > > > github
> > > > > to
> > > > > > >> which the dev list can benefit.
> > > > > > >> - Replies on update emails are reflected on the specific
> > issue/PR.
> > > > > > >> - Users can also choose to click on the link and go to
> github to
> > > > > > >> participate in discussion.
> > > > > > >> - We still have the ability to carry out dev@ only
> > conversation.
> > > > > > >>
> > > > > > >> Cons:
> > > > > > >> - Higher volume on dev list.
> > > > > > >> - Some discussions might not be suitable for dev@.
> (though I
> > > can't
> > > > > > think
> > > > > > >> of
> > > > > > >> why such conversation should happen on github either)
> > > > > > >>
> > > > > > >> -sz
> > > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
>
>

Re: [DISCUSS] Subscribe dev@ to Github Activities?

[Anirudh Acharya]

For concerns regarding signal and noise, I think we can get around that by
setting up the right kind of filters in the mail client.
Signal and Noise can be different for different people.


Regards,
Anirudh

On Thu, Jul 12, 2018 at 3:34 PM Haibin Lin  wrote:

> Agree. +1 for more transparency
>
> On Thu, Jul 12, 2018 at 3:27 PM, Zha, Sheng 
> wrote:
>
> > My intention is really just to bridge the gap between so much happening
> on
> > github v.s. "whatever didn't happen on dev list didn't happen".
> >
> > Also, since dev@ is intended to be an asynchronous way for community to
> > follow technical conversations, there wasn't really a requirement for
> > anyone to read all of them in the first place.
> >
> > Best regards,
> > -sz
> >
> > On 7/12/18, 3:20 PM, "Timur Shenkao"  wrote:
> >
> > Flink - yes
> > Spark - it was previously but not now
> >
> > Yeah, amount of messages would be tripled at least: Jira + Github
> > issue + PR
> >
> > On Thu, Jul 12, 2018 at 11:13 PM, Haibin Lin <
> haibin.lin@gmail.com
> > >
> > wrote:
> >
> > > I'm a bit concerned with the amount of emails flooding in. In the
> > past week
> > > there're 32 new issues and 35 new pull requests. This means on avg
> > 10 email
> > > per day and I doubt I'll read all of them.. Does the Spark
> community
> > > subscribe dev@ to github?
> > >
> > > Best,
> > > Haibin
> > >
> > > On Thu, Jul 12, 2018 at 3:08 PM, Pedro Larroy <
> > > pedro.larroy.li...@gmail.com>
> > > wrote:
> > >
> > > > -1   It's a lot of traffic, whomever wants to subscribe can do it
> > in
> > > > github. I'm afraid it will decrease signal to noise ratio in the
> > list.
> > > >
> > > > On Thu, Jul 12, 2018 at 11:32 PM Lin Yuan 
> > wrote:
> > > >
> > > > > +1
> > > > >
> > > > > On Thu, Jul 12, 2018 at 12:26 PM Anirudh Acharya <
> > > anirudhk...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > +1
> > > > > >
> > > > > > On Thu, Jul 12, 2018 at 11:51 AM Piyush Ghai <
> > ghai.piy...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > +1
> > > > > > > > On Jul 12, 2018, at 11:50 AM, Tianqi Chen <
> > > > tqc...@cs.washington.edu>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > +1
> > > > > > > >
> > > > > > > > On Thu, Jul 12, 2018 at 11:10 AM, Sheng Zha <
> > szha@gmail.com>
> > > > > > wrote:
> > > > > > > >
> > > > > > > >> Hi all,
> > > > > > > >>
> > > > > > > >> Should we subscribe dev list to github updates on mxnet
> > repo?
> > > Both
> > > > > > > github
> > > > > > > >> issues/PRs and the dev list are intended for technical
> > > discussions
> > > > > and
> > > > > > > in
> > > > > > > >> that aspect largely share the same goal. Since MXNet has
> > most
> > > > > activity
> > > > > > > >> github, this could help dev@ to become more active.
> Some
> > pros
> > > and
> > > > > > cons:
> > > > > > > >>
> > > > > > > >> Pros:
> > > > > > > >> - There have been many high quality discussions that
> > happen on
> > > > > github
> > > > > > to
> > > > > > > >> which the dev list can benefit.
> > > > > > > >> - Replies on update emails are reflected on the specific
> > > issue/PR.
> > > > > > > >> - Users can also choose to click on the link and go to
> > github to
> > > > > > > >> participate in discussion.
> > > > > > > >> - We still have the ability to carry out dev@ only
> > > conversation.
> > > > > > > >>
> > > > > > > >> Cons:
> > > > > > > >> - Higher volume on dev list.
> > > > > > > >> - Some discussions might not be suitable for dev@.
> > (though I
> > > > can't
> > > > > > > think
> > > > > > > >> of
> > > > > > > >> why such conversation should happen on github either)
> > > > > > > >>
> > > > > > > >> -sz
> > > > > > > >>
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> >
>

Re: Squash/Merge PRs

[Naveen Swamy]

Yes to insist on commit hygiene when rebase-merge. We have to open a JIRA
with Apache Infra to enable rebase-merge on the repo.

On Thu, Jul 12, 2018 at 3:21 PM, Marco de Abreu <
marco.g.ab...@googlemail.com.invalid> wrote:

> Fully agree, if we can get our commit hygiene up to industry standard, I
> don't see any problems in using rebase merge instead. For the short term I
> agree that it should be fine to rebase merge individual PRs with multiple
> contributors. But in my opinion we should then insist on people amending
> their commit history if we deem it below our standard. A PR should not be
> rebase merged if the history is not proper - verifying that is the
> responsibility of the merging committer, but ideally, we'd make people
> aware of problems early on. What do you think?
>
> In general, I think we should gradually start taking this into account when
> reviewing with the goal of all PRs having a proper commit history. This
> would allow us in the long term to completely move away from squashing.
>
> -Marco
>
> Pedro Larroy  schrieb am Fr., 13. Juli 2018,
> 00:07:
>
> > This is a great discussion, thanks for raising the question Naveen.
> >
> > From my experience working in all kinds of software project of varying
> > sizes and flavours:
> >
> >1. People should be aware of git rebase interactive and have more
> >hygiene in their PRs. If a PR is hygienic and is separated in a set of
> >semantic commits, it's better not squashed as it helps finding bugs /
> >bisecting. A "dirty" PR with WIP commits, is better squashed, or
> > requested
> >to rebase interactively on CR.
> >2. Mixing different semantic changes on a single PR is an
> anti-pattern,
> >for example fixing whitespace or reformatting many lines and changing
> > some
> >code which is hidden in a bunch of trivial changes and could cause a
> > bug or
> >major change of behaviour.
> >3. Agreed what with others have mentioned about small incremental
> steps
> >better than huge PRs. We also have JIRA or issues to relate a set of
> PRs
> >together. If not possible, PR with a set of non squashed commits is
> also
> >good.
> >
> > Hope it helps.
> >
> > Pedro.
> >
> > On Thu, Jul 12, 2018 at 11:47 PM Naveen Swamy 
> wrote:
> >
> > > @Aaron, I do not think most contributors(SDE or not) were even aware
> that
> > > their commits are getting squashed into one and thereby others losing
> > > credit on that work. I would assume no bad intentions there.
> > >
> > > @Hao,
> > > Agree to breaking down into small and reasonable sized PRs, but I think
> > > very small PRs will overwhelm the CI as it stands since it runs
> > > everything(this is a separate topic and needs fixing).
> > >
> > > For cases similar to Aaron's he can raise the PR for the doc
> > > work(regardless of fork or not) and add other contributors as
> co-authors.
> > >
> > > @Marco, co-author might not be suitable always suitable and agree with
> > Hao
> > > that should be used on exceptions. co-author also makes it hard to see
> > the
> > > contributions individually.
> > >
> > > @Marco, why can we not have Rebase merge enabled on the repo and use
> that
> > > when there are multiple contributors. This discussion is only about Not
> > > Squashing when there are multiple contributors and agree to continue
> the
> > > practice of Squashing in general.
> > >
> > > Until the tooling is fixed, I suggest to use the co-author feature when
> > > collaborating on a fork.
> > >
> > > Also, I just want to reiterate and request contributors to have
> > meaningful
> > > and fewer commits on PRs.
> > >
> > > Thanks, Naveen
> > >
> > >
> > > On Thu, Jul 12, 2018 at 11:40 AM, Marco de Abreu <
> > > marco.g.ab...@googlemail.com.invalid> wrote:
> > >
> > > > As of now it will require the usage of a merge bot as far as I
> > understand
> > > > this issue: https://github.com/python/miss-islington/issues/16.
> > Instead
> > > of
> > > > using the web interface do merge, we'd then trigger the bot to do the
> > > merge
> > > > on our behalf. There are pre-made solutions on the internet we might
> be
> > > > able to leverage, but it would take some time to get into it and
> adapt
> > > our
> > > > process.
> > > >
> > > > Additionally, GitHub has this feature request tracked internally.
> Let's
> > > see
> > > > when they get to add it.
> > > >
> > > > -Marco
> > > >
> > > >
> > > >
> > > > Aaron Markham  schrieb am Do., 12. Juli
> > 2018,
> > > > 21:33:
> > > >
> > > > > My point was about collaboration, or the lack thereof, and how the
> > > > tooling
> > > > > and apparent rewards from contribution statistics can reinforce
> lone
> > > > ranger
> > > > > behavior. People can and should be proud of their work, but why
> does
> > it
> > > > > have to be alone? Working within the context of a team is something
> > to
> > > be
> > > > > proud of too, but if your stats and standing are graded by how the
> > > > commits
> > > > > and merges land, and counting lin

Re: Access Permission of MXNet label bot

[Naveen Swamy]

+1 to running it inside a controlled environment.

On Thu, Jul 12, 2018 at 11:32 AM, Qing Lan  wrote:

> I think putting in the Infra can be a really good solution.
> We do not expose the credential to the outside and we can make sure it can
> be run in a timely manner.
>
> Thanks,
> Qing
>
> On 7/12/18, 11:11 AM, "Marco de Abreu" 
> wrote:
>
> Hello Cathy,
>
> unfortunately, we're not allowed to use bot accounts at Apache.
>
> An option we have is that we run your bot in our infrastructure with
> the
> credentials of a committer with the permission you have mentioned. The
> only
> restriction would be that you would not be able to access that server
> because the credentials are confidential user data of a committer.
> Would
> this work for you?
>
> Best regards,
> Marco
>
> On Thu, Jul 12, 2018 at 8:57 PM Yuelin Zhang <
> zhangyuelinch...@gmail.com>
> wrote:
>
> > Hi,
> >
> > I am working to improve the GitHub issue triage process by creating
> a label
> > bot(more info here
> > <
> > https://cwiki.apache.org/confluence/display/MXNET/Deep+
> Learning+Based+GitHub+Label+Bot
> > >
> > on
> > the cwiki), I have initial version of label bot ready. I would like
> to get
> > some opinions about access permission of MXNet label bot.
> >
> > Right now, all issues in MXNet repo are manually labeled. The
> process looks
> > like below:
> > First, contributors/committers go through the issues to triage them
> and
> > suggest labels and add comment on the issue requesting @committer to
> add
> > labels.
> >
> > This process will cause notification spam to both committers and
> users. The
> > long gap between user creating an issue and we labelling them will
> cause
> > the process time consuming and not very smooth.
> >
> > We want to simplify/automate this issue labeling process. Right now
> an
> > initial version of the label bot which can:
> >
> >1.  Send issue report daily. This report will show how many issue
> >open/closed, list uncommented/unlabeled issues and show an pie
> chart of
> >labels added in a week. Sample report here
> ><
> > https://cwiki.apache.org/confluence/display/MXNET/Deep+
> Learning+Based+GitHub+Label+Bot#DeepLearningBasedGitHubLabelBo
> t-SampleIssueReport
> > >
> >.
> >2.  Generate a spread sheet of unlabeled issues with recommended
> labels.
> >A contributor will open the sheet and fill in labels with
> reference of
> >bot's recommendations. In this case, contributor can deal with all
> >unlabeled issues at a time. Sample sheet here
> ><
> > https://cwiki.apache.org/confluence/display/MXNET/Deep+
> Learning+Based+GitHub+Label+Bot#DeepLearningBasedGitHubLabelBo
> t-SampleSpreadSheet
> > >
> >.
> >3.  Read labels filled in that sheet and apply labels to GitHub
> issues.
> >(tested on my personal Github repo)
> >
> >
> > This bot can be triggered daily so that all issues will be labeled
> in one
> > day without notification spam.
> >
> > *However,  this bot doesn't have access to add labels. We have two
> > options:*
> >
> > - Use a committer's Oauth token with limited scope. So far according
> to my
> > research, the most limited scope is "public_repo", this contains
> access to
> > code. Except this one, Github doesn't have smaller scope available
> to add
> > labels. Available scopes here
> > <
> > https://developer.github.com/apps/building-oauth-apps/
> understanding-scopes-for-oauth-apps/
> > >
> > .
> >
> > - Create a bot account having minimum permissions. For this, we will
> need
> > an account to be created from Apache Infrastructure with proper
> access and
> > they can control the access for the account through secret manager
> >  userguide/intro.html> .
> > Having a bot account is beneficial for future work, not only for
> labelling
> > but also other automatic processes.
> >
> > Please let me know if you have any other ideas to do this.
> >
> > Thanks,
> > Cathy
> >
>
>
>

Re: Squash/Merge PRs

[Marco de Abreu]

Coukd you elaborate why we would need a ticket for that? GitHub supports it
out of the box and it is enabled as far as I can tell. You just have to
press the little arrow besides the merge button.

-marco

Naveen Swamy  schrieb am Fr., 13. Juli 2018, 00:54:

> Yes to insist on commit hygiene when rebase-merge. We have to open a JIRA
> with Apache Infra to enable rebase-merge on the repo.
>
> On Thu, Jul 12, 2018 at 3:21 PM, Marco de Abreu <
> marco.g.ab...@googlemail.com.invalid> wrote:
>
> > Fully agree, if we can get our commit hygiene up to industry standard, I
> > don't see any problems in using rebase merge instead. For the short term
> I
> > agree that it should be fine to rebase merge individual PRs with multiple
> > contributors. But in my opinion we should then insist on people amending
> > their commit history if we deem it below our standard. A PR should not be
> > rebase merged if the history is not proper - verifying that is the
> > responsibility of the merging committer, but ideally, we'd make people
> > aware of problems early on. What do you think?
> >
> > In general, I think we should gradually start taking this into account
> when
> > reviewing with the goal of all PRs having a proper commit history. This
> > would allow us in the long term to completely move away from squashing.
> >
> > -Marco
> >
> > Pedro Larroy  schrieb am Fr., 13. Juli
> 2018,
> > 00:07:
> >
> > > This is a great discussion, thanks for raising the question Naveen.
> > >
> > > From my experience working in all kinds of software project of varying
> > > sizes and flavours:
> > >
> > >1. People should be aware of git rebase interactive and have more
> > >hygiene in their PRs. If a PR is hygienic and is separated in a set
> of
> > >semantic commits, it's better not squashed as it helps finding bugs
> /
> > >bisecting. A "dirty" PR with WIP commits, is better squashed, or
> > > requested
> > >to rebase interactively on CR.
> > >2. Mixing different semantic changes on a single PR is an
> > anti-pattern,
> > >for example fixing whitespace or reformatting many lines and
> changing
> > > some
> > >code which is hidden in a bunch of trivial changes and could cause a
> > > bug or
> > >major change of behaviour.
> > >3. Agreed what with others have mentioned about small incremental
> > steps
> > >better than huge PRs. We also have JIRA or issues to relate a set of
> > PRs
> > >together. If not possible, PR with a set of non squashed commits is
> > also
> > >good.
> > >
> > > Hope it helps.
> > >
> > > Pedro.
> > >
> > > On Thu, Jul 12, 2018 at 11:47 PM Naveen Swamy 
> > wrote:
> > >
> > > > @Aaron, I do not think most contributors(SDE or not) were even aware
> > that
> > > > their commits are getting squashed into one and thereby others losing
> > > > credit on that work. I would assume no bad intentions there.
> > > >
> > > > @Hao,
> > > > Agree to breaking down into small and reasonable sized PRs, but I
> think
> > > > very small PRs will overwhelm the CI as it stands since it runs
> > > > everything(this is a separate topic and needs fixing).
> > > >
> > > > For cases similar to Aaron's he can raise the PR for the doc
> > > > work(regardless of fork or not) and add other contributors as
> > co-authors.
> > > >
> > > > @Marco, co-author might not be suitable always suitable and agree
> with
> > > Hao
> > > > that should be used on exceptions. co-author also makes it hard to
> see
> > > the
> > > > contributions individually.
> > > >
> > > > @Marco, why can we not have Rebase merge enabled on the repo and use
> > that
> > > > when there are multiple contributors. This discussion is only about
> Not
> > > > Squashing when there are multiple contributors and agree to continue
> > the
> > > > practice of Squashing in general.
> > > >
> > > > Until the tooling is fixed, I suggest to use the co-author feature
> when
> > > > collaborating on a fork.
> > > >
> > > > Also, I just want to reiterate and request contributors to have
> > > meaningful
> > > > and fewer commits on PRs.
> > > >
> > > > Thanks, Naveen
> > > >
> > > >
> > > > On Thu, Jul 12, 2018 at 11:40 AM, Marco de Abreu <
> > > > marco.g.ab...@googlemail.com.invalid> wrote:
> > > >
> > > > > As of now it will require the usage of a merge bot as far as I
> > > understand
> > > > > this issue: https://github.com/python/miss-islington/issues/16.
> > > Instead
> > > > of
> > > > > using the web interface do merge, we'd then trigger the bot to do
> the
> > > > merge
> > > > > on our behalf. There are pre-made solutions on the internet we
> might
> > be
> > > > > able to leverage, but it would take some time to get into it and
> > adapt
> > > > our
> > > > > process.
> > > > >
> > > > > Additionally, GitHub has this feature request tracked internally.
> > Let's
> > > > see
> > > > > when they get to add it.
> > > > >
> > > > > -Marco
> > > > >
> > > > >
> > > > >
> > > > > Aaron Markham  schrieb am Do., 12. Juli
> > > 2018,
> >

Re: Deprecate python 2

[Marco de Abreu]

As far as I know is the epel repository not considered stable.

Chen HY  schrieb am Fr., 13. Juli 2018, 00:18:

> CentOS 7 has Python 3.4.8 and python 3.6.3 in epel repo.
> Is that stable ?
> HY
> 发件人: Marco de Abreu
> 发送时间: 2018年7月12日 23:00
> 收件人: dev@mxnet.incubator.apache.org
> 主题: Re: Deprecate python 2
>
> CentOS 7, for example, does not offer stable Python 3 support. We're using
> an unstable version in our CI to verify it none the less. I think that's a
> hard stop for quite a few users.
>
> -Marco
>
> Pedro Larroy  schrieb am Do., 12. Juli 2018,
> 23:51:
>
> > Hi
> >
> > I would like to know your opinion in regards to deprecating and removing
> > Python 2. Maybe for MXNet 2.0 ?
> >
> > What's the reason to have support for Python2?
> >
> > Pedro.
> >
>
>

Re: Deprecate python 2

[Marco de Abreu]

Sorry, I pressed the send button too early. I think epel repository is not
deemed stable enough that it qualifies to be used in all Enterprise
environments - epel itself has a stable and a release repository. I'm not
very familiar with CentOS or RHEL, but that's what I read when I designed
the CentOS docker containers. If anybody has more knowledge I'm happy to
get corrected here :)

-Marco

Marco de Abreu  schrieb am Fr., 13. Juli
2018, 01:23:

> As far as I know is the epel repository not considered stable.
>
> Chen HY  schrieb am Fr., 13. Juli 2018, 00:18:
>
>> CentOS 7 has Python 3.4.8 and python 3.6.3 in epel repo.
>> Is that stable ?
>> HY
>> 发件人: Marco de Abreu
>> 发送时间: 2018年7月12日 23:00
>> 收件人: dev@mxnet.incubator.apache.org
>> 主题: Re: Deprecate python 2
>>
>> CentOS 7, for example, does not offer stable Python 3 support. We're using
>> an unstable version in our CI to verify it none the less. I think that's a
>> hard stop for quite a few users.
>>
>> -Marco
>>
>> Pedro Larroy  schrieb am Do., 12. Juli
>> 2018,
>> 23:51:
>>
>> > Hi
>> >
>> > I would like to know your opinion in regards to deprecating and removing
>> > Python 2. Maybe for MXNet 2.0 ?
>> >
>> > What's the reason to have support for Python2?
>> >
>> > Pedro.
>> >
>>
>>

Re: Squash/Merge PRs

[Naveen Swamy]

You are right, its already enabled :) I saw that option greyed out for one
of the PR(for a different reason) and assumed we need INFRA to enable.

On Thu, Jul 12, 2018 at 4:22 PM, Marco de Abreu <
marco.g.ab...@googlemail.com.invalid> wrote:

> Coukd you elaborate why we would need a ticket for that? GitHub supports it
> out of the box and it is enabled as far as I can tell. You just have to
> press the little arrow besides the merge button.
>
> -marco
>
> Naveen Swamy  schrieb am Fr., 13. Juli 2018, 00:54:
>
> > Yes to insist on commit hygiene when rebase-merge. We have to open a JIRA
> > with Apache Infra to enable rebase-merge on the repo.
> >
> > On Thu, Jul 12, 2018 at 3:21 PM, Marco de Abreu <
> > marco.g.ab...@googlemail.com.invalid> wrote:
> >
> > > Fully agree, if we can get our commit hygiene up to industry standard,
> I
> > > don't see any problems in using rebase merge instead. For the short
> term
> > I
> > > agree that it should be fine to rebase merge individual PRs with
> multiple
> > > contributors. But in my opinion we should then insist on people
> amending
> > > their commit history if we deem it below our standard. A PR should not
> be
> > > rebase merged if the history is not proper - verifying that is the
> > > responsibility of the merging committer, but ideally, we'd make people
> > > aware of problems early on. What do you think?
> > >
> > > In general, I think we should gradually start taking this into account
> > when
> > > reviewing with the goal of all PRs having a proper commit history. This
> > > would allow us in the long term to completely move away from squashing.
> > >
> > > -Marco
> > >
> > > Pedro Larroy  schrieb am Fr., 13. Juli
> > 2018,
> > > 00:07:
> > >
> > > > This is a great discussion, thanks for raising the question Naveen.
> > > >
> > > > From my experience working in all kinds of software project of
> varying
> > > > sizes and flavours:
> > > >
> > > >1. People should be aware of git rebase interactive and have more
> > > >hygiene in their PRs. If a PR is hygienic and is separated in a
> set
> > of
> > > >semantic commits, it's better not squashed as it helps finding
> bugs
> > /
> > > >bisecting. A "dirty" PR with WIP commits, is better squashed, or
> > > > requested
> > > >to rebase interactively on CR.
> > > >2. Mixing different semantic changes on a single PR is an
> > > anti-pattern,
> > > >for example fixing whitespace or reformatting many lines and
> > changing
> > > > some
> > > >code which is hidden in a bunch of trivial changes and could
> cause a
> > > > bug or
> > > >major change of behaviour.
> > > >3. Agreed what with others have mentioned about small incremental
> > > steps
> > > >better than huge PRs. We also have JIRA or issues to relate a set
> of
> > > PRs
> > > >together. If not possible, PR with a set of non squashed commits
> is
> > > also
> > > >good.
> > > >
> > > > Hope it helps.
> > > >
> > > > Pedro.
> > > >
> > > > On Thu, Jul 12, 2018 at 11:47 PM Naveen Swamy 
> > > wrote:
> > > >
> > > > > @Aaron, I do not think most contributors(SDE or not) were even
> aware
> > > that
> > > > > their commits are getting squashed into one and thereby others
> losing
> > > > > credit on that work. I would assume no bad intentions there.
> > > > >
> > > > > @Hao,
> > > > > Agree to breaking down into small and reasonable sized PRs, but I
> > think
> > > > > very small PRs will overwhelm the CI as it stands since it runs
> > > > > everything(this is a separate topic and needs fixing).
> > > > >
> > > > > For cases similar to Aaron's he can raise the PR for the doc
> > > > > work(regardless of fork or not) and add other contributors as
> > > co-authors.
> > > > >
> > > > > @Marco, co-author might not be suitable always suitable and agree
> > with
> > > > Hao
> > > > > that should be used on exceptions. co-author also makes it hard to
> > see
> > > > the
> > > > > contributions individually.
> > > > >
> > > > > @Marco, why can we not have Rebase merge enabled on the repo and
> use
> > > that
> > > > > when there are multiple contributors. This discussion is only about
> > Not
> > > > > Squashing when there are multiple contributors and agree to
> continue
> > > the
> > > > > practice of Squashing in general.
> > > > >
> > > > > Until the tooling is fixed, I suggest to use the co-author feature
> > when
> > > > > collaborating on a fork.
> > > > >
> > > > > Also, I just want to reiterate and request contributors to have
> > > > meaningful
> > > > > and fewer commits on PRs.
> > > > >
> > > > > Thanks, Naveen
> > > > >
> > > > >
> > > > > On Thu, Jul 12, 2018 at 11:40 AM, Marco de Abreu <
> > > > > marco.g.ab...@googlemail.com.invalid> wrote:
> > > > >
> > > > > > As of now it will require the usage of a merge bot as far as I
> > > > understand
> > > > > > this issue: https://github.com/python/miss-islington/issues/16.
> > > > Instead
> > > > > of
> > > > > > using the web interface do merge, we'd th

Re: Squash/Merge PRs

[Marco de Abreu]

Excellent :)

I don't think we need a formal vote for this but rather let this be lazy
consensus if nobody minds.

Could we maybe revisit this decision in 1 or 2 months and then assess the
state of commit history in all PRs (including squashed ones) and with focus
on rebase merged PRs?

-Marco

Naveen Swamy  schrieb am Fr., 13. Juli 2018, 01:33:

> You are right, its already enabled :) I saw that option greyed out for one
> of the PR(for a different reason) and assumed we need INFRA to enable.
>
> On Thu, Jul 12, 2018 at 4:22 PM, Marco de Abreu <
> marco.g.ab...@googlemail.com.invalid> wrote:
>
> > Coukd you elaborate why we would need a ticket for that? GitHub supports
> it
> > out of the box and it is enabled as far as I can tell. You just have to
> > press the little arrow besides the merge button.
> >
> > -marco
> >
> > Naveen Swamy  schrieb am Fr., 13. Juli 2018, 00:54:
> >
> > > Yes to insist on commit hygiene when rebase-merge. We have to open a
> JIRA
> > > with Apache Infra to enable rebase-merge on the repo.
> > >
> > > On Thu, Jul 12, 2018 at 3:21 PM, Marco de Abreu <
> > > marco.g.ab...@googlemail.com.invalid> wrote:
> > >
> > > > Fully agree, if we can get our commit hygiene up to industry
> standard,
> > I
> > > > don't see any problems in using rebase merge instead. For the short
> > term
> > > I
> > > > agree that it should be fine to rebase merge individual PRs with
> > multiple
> > > > contributors. But in my opinion we should then insist on people
> > amending
> > > > their commit history if we deem it below our standard. A PR should
> not
> > be
> > > > rebase merged if the history is not proper - verifying that is the
> > > > responsibility of the merging committer, but ideally, we'd make
> people
> > > > aware of problems early on. What do you think?
> > > >
> > > > In general, I think we should gradually start taking this into
> account
> > > when
> > > > reviewing with the goal of all PRs having a proper commit history.
> This
> > > > would allow us in the long term to completely move away from
> squashing.
> > > >
> > > > -Marco
> > > >
> > > > Pedro Larroy  schrieb am Fr., 13. Juli
> > > 2018,
> > > > 00:07:
> > > >
> > > > > This is a great discussion, thanks for raising the question Naveen.
> > > > >
> > > > > From my experience working in all kinds of software project of
> > varying
> > > > > sizes and flavours:
> > > > >
> > > > >1. People should be aware of git rebase interactive and have
> more
> > > > >hygiene in their PRs. If a PR is hygienic and is separated in a
> > set
> > > of
> > > > >semantic commits, it's better not squashed as it helps finding
> > bugs
> > > /
> > > > >bisecting. A "dirty" PR with WIP commits, is better squashed, or
> > > > > requested
> > > > >to rebase interactively on CR.
> > > > >2. Mixing different semantic changes on a single PR is an
> > > > anti-pattern,
> > > > >for example fixing whitespace or reformatting many lines and
> > > changing
> > > > > some
> > > > >code which is hidden in a bunch of trivial changes and could
> > cause a
> > > > > bug or
> > > > >major change of behaviour.
> > > > >3. Agreed what with others have mentioned about small
> incremental
> > > > steps
> > > > >better than huge PRs. We also have JIRA or issues to relate a
> set
> > of
> > > > PRs
> > > > >together. If not possible, PR with a set of non squashed commits
> > is
> > > > also
> > > > >good.
> > > > >
> > > > > Hope it helps.
> > > > >
> > > > > Pedro.
> > > > >
> > > > > On Thu, Jul 12, 2018 at 11:47 PM Naveen Swamy 
> > > > wrote:
> > > > >
> > > > > > @Aaron, I do not think most contributors(SDE or not) were even
> > aware
> > > > that
> > > > > > their commits are getting squashed into one and thereby others
> > losing
> > > > > > credit on that work. I would assume no bad intentions there.
> > > > > >
> > > > > > @Hao,
> > > > > > Agree to breaking down into small and reasonable sized PRs, but I
> > > think
> > > > > > very small PRs will overwhelm the CI as it stands since it runs
> > > > > > everything(this is a separate topic and needs fixing).
> > > > > >
> > > > > > For cases similar to Aaron's he can raise the PR for the doc
> > > > > > work(regardless of fork or not) and add other contributors as
> > > > co-authors.
> > > > > >
> > > > > > @Marco, co-author might not be suitable always suitable and agree
> > > with
> > > > > Hao
> > > > > > that should be used on exceptions. co-author also makes it hard
> to
> > > see
> > > > > the
> > > > > > contributions individually.
> > > > > >
> > > > > > @Marco, why can we not have Rebase merge enabled on the repo and
> > use
> > > > that
> > > > > > when there are multiple contributors. This discussion is only
> about
> > > Not
> > > > > > Squashing when there are multiple contributors and agree to
> > continue
> > > > the
> > > > > > practice of Squashing in general.
> > > > > >
> > > > > > Until the tooling is fixed, I suggest to use the co-author
> f

Re: Squash/Merge PRs

[eric xie]

-1

We should stick with always using squash. It maintains PR reference in commit 
history. It is also common practice.

If you want to included commits from multiple contributors in a single PR, open 
a branch and make PRs to that branch. Then only use rebase when merging that 
branch to master.

Thanks,
Eric

On 2018/07/12 23:38:54, Marco de Abreu  
wrote: 
> Excellent :)
> 
> I don't think we need a formal vote for this but rather let this be lazy
> consensus if nobody minds.
> 
> Could we maybe revisit this decision in 1 or 2 months and then assess the
> state of commit history in all PRs (including squashed ones) and with focus
> on rebase merged PRs?
> 
> -Marco
> 
> Naveen Swamy  schrieb am Fr., 13. Juli 2018, 01:33:
> 
> > You are right, its already enabled :) I saw that option greyed out for one
> > of the PR(for a different reason) and assumed we need INFRA to enable.
> >
> > On Thu, Jul 12, 2018 at 4:22 PM, Marco de Abreu <
> > marco.g.ab...@googlemail.com.invalid> wrote:
> >
> > > Coukd you elaborate why we would need a ticket for that? GitHub supports
> > it
> > > out of the box and it is enabled as far as I can tell. You just have to
> > > press the little arrow besides the merge button.
> > >
> > > -marco
> > >
> > > Naveen Swamy  schrieb am Fr., 13. Juli 2018, 00:54:
> > >
> > > > Yes to insist on commit hygiene when rebase-merge. We have to open a
> > JIRA
> > > > with Apache Infra to enable rebase-merge on the repo.
> > > >
> > > > On Thu, Jul 12, 2018 at 3:21 PM, Marco de Abreu <
> > > > marco.g.ab...@googlemail.com.invalid> wrote:
> > > >
> > > > > Fully agree, if we can get our commit hygiene up to industry
> > standard,
> > > I
> > > > > don't see any problems in using rebase merge instead. For the short
> > > term
> > > > I
> > > > > agree that it should be fine to rebase merge individual PRs with
> > > multiple
> > > > > contributors. But in my opinion we should then insist on people
> > > amending
> > > > > their commit history if we deem it below our standard. A PR should
> > not
> > > be
> > > > > rebase merged if the history is not proper - verifying that is the
> > > > > responsibility of the merging committer, but ideally, we'd make
> > people
> > > > > aware of problems early on. What do you think?
> > > > >
> > > > > In general, I think we should gradually start taking this into
> > account
> > > > when
> > > > > reviewing with the goal of all PRs having a proper commit history.
> > This
> > > > > would allow us in the long term to completely move away from
> > squashing.
> > > > >
> > > > > -Marco
> > > > >
> > > > > Pedro Larroy  schrieb am Fr., 13. Juli
> > > > 2018,
> > > > > 00:07:
> > > > >
> > > > > > This is a great discussion, thanks for raising the question Naveen.
> > > > > >
> > > > > > From my experience working in all kinds of software project of
> > > varying
> > > > > > sizes and flavours:
> > > > > >
> > > > > >1. People should be aware of git rebase interactive and have
> > more
> > > > > >hygiene in their PRs. If a PR is hygienic and is separated in a
> > > set
> > > > of
> > > > > >semantic commits, it's better not squashed as it helps finding
> > > bugs
> > > > /
> > > > > >bisecting. A "dirty" PR with WIP commits, is better squashed, or
> > > > > > requested
> > > > > >to rebase interactively on CR.
> > > > > >2. Mixing different semantic changes on a single PR is an
> > > > > anti-pattern,
> > > > > >for example fixing whitespace or reformatting many lines and
> > > > changing
> > > > > > some
> > > > > >code which is hidden in a bunch of trivial changes and could
> > > cause a
> > > > > > bug or
> > > > > >major change of behaviour.
> > > > > >3. Agreed what with others have mentioned about small
> > incremental
> > > > > steps
> > > > > >better than huge PRs. We also have JIRA or issues to relate a
> > set
> > > of
> > > > > PRs
> > > > > >together. If not possible, PR with a set of non squashed commits
> > > is
> > > > > also
> > > > > >good.
> > > > > >
> > > > > > Hope it helps.
> > > > > >
> > > > > > Pedro.
> > > > > >
> > > > > > On Thu, Jul 12, 2018 at 11:47 PM Naveen Swamy 
> > > > > wrote:
> > > > > >
> > > > > > > @Aaron, I do not think most contributors(SDE or not) were even
> > > aware
> > > > > that
> > > > > > > their commits are getting squashed into one and thereby others
> > > losing
> > > > > > > credit on that work. I would assume no bad intentions there.
> > > > > > >
> > > > > > > @Hao,
> > > > > > > Agree to breaking down into small and reasonable sized PRs, but I
> > > > think
> > > > > > > very small PRs will overwhelm the CI as it stands since it runs
> > > > > > > everything(this is a separate topic and needs fixing).
> > > > > > >
> > > > > > > For cases similar to Aaron's he can raise the PR for the doc
> > > > > > > work(regardless of fork or not) and add other contributors as
> > > > > co-authors.
> > > > > > >
> > > > > > > @Marco, co-author might not be suitable alway

[RESULT][VOTE] Release MXNet version 1.2.1.RC1

[Roshani Nagmote]

Hi All,

Thank you for spending the time to test MXNet 1.2.1.RC1 release.
This vote passes with 9 +1 (binding votes).

Binding +1:
Haibin
Indhu
Sandeep
Jun
Zhi
Naveen
Lin
Sergio
Hao

Vote thread:

*https://lists.apache.org/thread.html/6a0459a54dd0b13fc89f653af91306810aa83d5d1a578a2abbac89fe@%3Cdev.mxnet.apache.org%3E
*

I will continue with the release process on general@ and the release
announcement
will follow in the next few days.

Thanks,
Roshani

Re: [RESULT][VOTE] Release MXNet version 1.2.1.RC1

[Roshani Nagmote]

Hi All,

Updating the results.
This vote passes with 9 +1 votes (1 binding) and no 0 or -1 votes.

*+1 votes*

*IPMC Members:*
- Sergio

*Committers*:
- Haibin
- Indhu
- Sandeep
- Jun
- Zhi
- Naveen

*Contributors:*
- Lin
- Hao

Vote thread:

*https://lists.apache.org/thread.html/6a0459a54dd0b13fc89f653af91306810aa83d5d1a578a2abbac89fe@%3Cdev.mxnet.apache.org%3E
*

I will continue with the release process on general@ and the release
announcement
will follow in the next few days.

Thanks,
Roshani


On Thu, Jul 12, 2018 at 6:10 PM Roshani Nagmote 
wrote:

> Hi All,
>
> Thank you for spending the time to test MXNet 1.2.1.RC1 release.
> This vote passes with 9 +1 (binding votes).
>
> Binding +1:
> Haibin
> Indhu
> Sandeep
> Jun
> Zhi
> Naveen
> Lin
> Sergio
> Hao
>
> Vote thread:
>
> *https://lists.apache.org/thread.html/6a0459a54dd0b13fc89f653af91306810aa83d5d1a578a2abbac89fe@%3Cdev.mxnet.apache.org%3E
> *
>
> I will continue with the release process on general@ and the release 
> announcement
> will follow in the next few days.
>
> Thanks,
> Roshani
>

Re: Access Permission of MXNet label bot

[Yuelin Zhang]

That's a very good solution! I will provide documentations about how to
run/test/maintain it. Will reach out to see how can we collaborate on it.

Thanks,
Cathy

On Thu, Jul 12, 2018 at 4:09 PM, Naveen Swamy  wrote:

> +1 to running it inside a controlled environment.
>
> On Thu, Jul 12, 2018 at 11:32 AM, Qing Lan  wrote:
>
> > I think putting in the Infra can be a really good solution.
> > We do not expose the credential to the outside and we can make sure it
> can
> > be run in a timely manner.
> >
> > Thanks,
> > Qing
> >
> > On 7/12/18, 11:11 AM, "Marco de Abreu"  INVALID>
> > wrote:
> >
> > Hello Cathy,
> >
> > unfortunately, we're not allowed to use bot accounts at Apache.
> >
> > An option we have is that we run your bot in our infrastructure with
> > the
> > credentials of a committer with the permission you have mentioned.
> The
> > only
> > restriction would be that you would not be able to access that server
> > because the credentials are confidential user data of a committer.
> > Would
> > this work for you?
> >
> > Best regards,
> > Marco
> >
> > On Thu, Jul 12, 2018 at 8:57 PM Yuelin Zhang <
> > zhangyuelinch...@gmail.com>
> > wrote:
> >
> > > Hi,
> > >
> > > I am working to improve the GitHub issue triage process by creating
> > a label
> > > bot(more info here
> > > <
> > > https://cwiki.apache.org/confluence/display/MXNET/Deep+
> > Learning+Based+GitHub+Label+Bot
> > > >
> > > on
> > > the cwiki), I have initial version of label bot ready. I would like
> > to get
> > > some opinions about access permission of MXNet label bot.
> > >
> > > Right now, all issues in MXNet repo are manually labeled. The
> > process looks
> > > like below:
> > > First, contributors/committers go through the issues to triage them
> > and
> > > suggest labels and add comment on the issue requesting @committer
> to
> > add
> > > labels.
> > >
> > > This process will cause notification spam to both committers and
> > users. The
> > > long gap between user creating an issue and we labelling them will
> > cause
> > > the process time consuming and not very smooth.
> > >
> > > We want to simplify/automate this issue labeling process. Right now
> > an
> > > initial version of the label bot which can:
> > >
> > >1.  Send issue report daily. This report will show how many
> issue
> > >open/closed, list uncommented/unlabeled issues and show an pie
> > chart of
> > >labels added in a week. Sample report here
> > ><
> > > https://cwiki.apache.org/confluence/display/MXNET/Deep+
> > Learning+Based+GitHub+Label+Bot#DeepLearningBasedGitHubLabelBo
> > t-SampleIssueReport
> > > >
> > >.
> > >2.  Generate a spread sheet of unlabeled issues with recommended
> > labels.
> > >A contributor will open the sheet and fill in labels with
> > reference of
> > >bot's recommendations. In this case, contributor can deal with
> all
> > >unlabeled issues at a time. Sample sheet here
> > ><
> > > https://cwiki.apache.org/confluence/display/MXNET/Deep+
> > Learning+Based+GitHub+Label+Bot#DeepLearningBasedGitHubLabelBo
> > t-SampleSpreadSheet
> > > >
> > >.
> > >3.  Read labels filled in that sheet and apply labels to GitHub
> > issues.
> > >(tested on my personal Github repo)
> > >
> > >
> > > This bot can be triggered daily so that all issues will be labeled
> > in one
> > > day without notification spam.
> > >
> > > *However,  this bot doesn't have access to add labels. We have two
> > > options:*
> > >
> > > - Use a committer's Oauth token with limited scope. So far
> according
> > to my
> > > research, the most limited scope is "public_repo", this contains
> > access to
> > > code. Except this one, Github doesn't have smaller scope available
> > to add
> > > labels. Available scopes here
> > > <
> > > https://developer.github.com/apps/building-oauth-apps/
> > understanding-scopes-for-oauth-apps/
> > > >
> > > .
> > >
> > > - Create a bot account having minimum permissions. For this, we
> will
> > need
> > > an account to be created from Apache Infrastructure with proper
> > access and
> > > they can control the access for the account through secret manager
> > >  > userguide/intro.html> .
> > > Having a bot account is beneficial for future work, not only for
> > labelling
> > > but also other automatic processes.
> > >
> > > Please let me know if you have any other ideas to do this.
> > >
> > > Thanks,
> > > Cathy
> > >
> >
> >
> >
>

答复: Deprecate python 2

[Chen HY]

Could you please finding the original document you have read about EPEL?
I just check the EPEL website again, failed to find a stable repository you 
mentioned.
As my understanding, EPEL repo is as reliable as other non-commercial rpm 
repository.

Website: https://fedoraproject.org/wiki/EPEL

HY


发件人: Marco de Abreu
发送时间: 2018年7月13日 0:27
收件人: dev@mxnet.incubator.apache.org
主题: Re: Deprecate python 2

Sorry, I pressed the send button too early. I think epel repository is not
deemed stable enough that it qualifies to be used in all Enterprise
environments - epel itself has a stable and a release repository. I'm not
very familiar with CentOS or RHEL, but that's what I read when I designed
the CentOS docker containers. If anybody has more knowledge I'm happy to
get corrected here :)

-Marco

Marco de Abreu  schrieb am Fr., 13. Juli
2018, 01:23:

> As far as I know is the epel repository not considered stable.
>
> Chen HY  schrieb am Fr., 13. Juli 2018, 00:18:
>
>> CentOS 7 has Python 3.4.8 and python 3.6.3 in epel repo.
>> Is that stable ?
>> HY
>> 发件人: Marco de Abreu
>> 发送时间: 2018年7月12日 23:00
>> 收件人: dev@mxnet.incubator.apache.org
>> 主题: Re: Deprecate python 2
>>
>> CentOS 7, for example, does not offer stable Python 3 support. We're using
>> an unstable version in our CI to verify it none the less. I think that's a
>> hard stop for quite a few users.
>>
>> -Marco
>>
>> Pedro Larroy  schrieb am Do., 12. Juli
>> 2018,
>> 23:51:
>>
>> > Hi
>> >
>> > I would like to know your opinion in regards to deprecating and removing
>> > Python 2. Maybe for MXNet 2.0 ?
>> >
>> > What's the reason to have support for Python2?
>> >
>> > Pedro.
>> >
>>
>>