Re: Vote to stop using JIRA

[Yasser Zamani]

On 6/8/2018 9:57 PM, Eric Xie wrote:
> Hi,
> 
> Since all of MXNet's development happens on Github, I think it's sufficient 
> to use Github Issues and Github Projects for tracking. There are also many 
> other plugins you can add to Github if issues and projects are not enough.
> 
> It's very easy to cross reference PRs and issues for tracking. In comparison, 
> JIRA is an outdated system with very little features and no integration with 
> Github. I think using it achieves nothing but additional overhead.

-1 as I afraid it may violate "Apache Way". Microsoft is going to buy
GitHub. What happens to Apache histories if one day he decided to drop
GitHub data including Apache projects histories?! or decided to change
usage license or payment?! and etc!

However, I found it seems was legally OK in 2016 [1] BUT I think we must
ask again also "general@incubator and/or community@apache and/or board
rather than at legal-discuss" [1]. (at least informs them about the
state of the art).

I personally prefer to stick together with Apache INFRA Team and ask
them to automate any overhead work instead. e.g. they already have a
nice JIRA and GitHub PR connection [2].

Regards.

[1]
https://lists.apache.org/thread.html/2890619eb1ca049f057c95a3378efc7be5d54d646c693d2e2560c103@%3Clegal-discuss.apache.org%3E
[2]
https://github.com/openzipkin/openzipkin.github.io/issues/51#issuecomment-250877803
 "For our project, a PR should have a corresponding JIRA issue -- we use
GH PR templates to tell contributors what to do . For issue tracking we
use Apache JIRA. Apache has webhooks in Github that detects the "JIRA
token" in a PR title (for example, the token for this PR is CB-11860 and
this makes any GH comments in the PR reflect back to the JIRA issue (but
not vice versa), and it is also sent to a project mailing list as well."

Re: Vote to stop using JIRA

[Jun Wu]

+1

I have used Jira for a few years. At the time, it had much richer
customized features, at the cost of raising a specialized team developing
Jira plugins, than what the Jira system has for MXNet. Even so, I'm still
not a big fan of it. The learning curve is quite steep to make the personal
dashboard aligned with the team's. In the open source world, we can neither
afford having dedicated Jira support from a specialized team nor increasing
unnecessary overhead of developers. After using Jira for managing the
development work of MXNet for several months, I don't see any advantages of
using Jira with currently available features over GitHub Projects tracking
system.

On Fri, Jun 8, 2018 at 7:17 PM, Thomas DELTEIL 
wrote:

> +0.5
>
> Thanks Timur for the constructive feedback!
>
> For me the problem is exactly as Anirudh raised, I am not a big fan of it
> but I don't think JIRA has been given a fair shot. The problem lies not so
> much with the tracking platform but rather with the contributors following
> the project management guidelines.
>
> All the best,
>
> Thomas
>
>
> 2018-06-08 17:05 GMT-07:00 Eric Xie :
>
> > Github has many project management tools. Any of them would be a better
> > choice than JIRA.
> >
> > Thanks,
> > Eric
> >
> > On 2018/06/09 00:02:55, Timur Shenkao  wrote:
> > > Hello guys!
> > > Let me add five cents step-by-step. Some kind of "external viewpoint"
> (I
> > > don't work in Amazon or Intel).
> > > 1) Thanks a lot of for interesting product / framework like MXNet.
> > > Currently, I use pretty standard DL stack: Keras + TF and some other
> less
> > > popular libraries. But I am not completely satisfied so I am looking
> for
> > > something new for my upcoming projects. So, I "investigate" MXNet now.
> > >
> > > 2)* I completely agree with Naveen*.
> > >
> > > 3) If you really want to see wide adoption of MXNet (like Spark, Kafka,
> > > Flink, etc.), then tasks should be documented in some task tracker.
> > > In this case everyone would be able to see the progress of the project,
> > > understand which features, bug fixes are included into the next
> release,
> > > intended to appear in near future. Developers, contributors, committers
> > can
> > > see the progress, the cadence of the project. Links to docs, Github
> PRs,
> > > roadmaps, proposals, build results, other JIRAs are present in a JIRA
> > > ticket so it's easy to navigate for everyone.
> > > Github is suitable for code review and management. But it can't
> > substitute
> > > tracker system. Even small team will have hundreds of PRs, issues
> pretty
> > > soon and chaos arises. Besides, there is no much fun (for "external"
> > user)
> > > in jumping from one Github PR to another trying to understand why &
> when
> > &
> > > in which commit something appeared.
> > > I understand that MXNet was promoted into Apache incubator to enlarge
> > > community, build ecosystem around it and for some other "commercial
> > > interests". Without clear vision and understanding of project's status
> &
> > > future, nobody will take MXNet into production or build MXNetT
> "plugin".
> > >
> > > 4)  "*There are 900+ issues, that once in a while gets closed without
> any
> > > reason has happened already once*". It also happens with other
> > Github-based
> > > projects. For example, Presto committers go through list of issues once
> > or
> > > twice a year. And close vast majority of them with resolutions like
> > "Won't
> > > fix", "I don't like it", etc.
> > >
> > > 5) JIRA is very configurable, one does not have to jump from board to
> > board
> > > to edit / enter ticket info. I have Apache's JIRA account. And I can
> > read,
> > > add comments & files / patches to tickets, create tickets in some
> > projects.
> > > But privileges can be configured.
> > >
> > >
> > > Timur
> > >
> > > On Fri, Jun 8, 2018 at 10:48 PM, Hen  wrote:
> > >
> > > > Are you saying only committers can make JIRA accounts?
> > > >
> > > > On Fri, Jun 8, 2018 at 2:41 PM Qing Lan  wrote:
> > > >
> > > > > + 0
> > > > > Can we keep this optional? Not totally abandon or support.
> > > > > Pros:
> > > > > I used JIRA to track most of my PRs and can place them together at
> > one
> > > > > place. It also being helpful if we find some issues and group them
> > > > together
> > > > > as one case.
> > > > > Cons:
> > > > > Currently JIRA does not allow someone who is not contributor to
> file
> > an
> > > > > issue which makes first-time contributor hard to submit a PR.
> > > > >
> > > > > Thanks,
> > > > > Qing
> > > > >
> > > > >
> > > > > On 6/8/18, 2:27 PM, "Hao Jin"  wrote:
> > > > >
> > > > > +0.5
> > > > > I'm an SDE working for MXNet Engine team at AWS and I've been
> > using
> > > > > JIRA
> > > > > for nearly every single PR (28 out of 29 PR at this moment) I
> > created
> > > > > since
> > > > > I joined the team 3 months ago. I wouldn't say it's a really
> bad
> > > > > experience, but definitely not good.
> > > > > I do agree 

Re: Vote to stop using JIRA

[Thomas DELTEIL]

+0.5

Thanks Timur for the constructive feedback!

For me the problem is exactly as Anirudh raised, I am not a big fan of it
but I don't think JIRA has been given a fair shot. The problem lies not so
much with the tracking platform but rather with the contributors following
the project management guidelines.

All the best,

Thomas


2018-06-08 17:05 GMT-07:00 Eric Xie :

> Github has many project management tools. Any of them would be a better
> choice than JIRA.
>
> Thanks,
> Eric
>
> On 2018/06/09 00:02:55, Timur Shenkao  wrote:
> > Hello guys!
> > Let me add five cents step-by-step. Some kind of "external viewpoint" (I
> > don't work in Amazon or Intel).
> > 1) Thanks a lot of for interesting product / framework like MXNet.
> > Currently, I use pretty standard DL stack: Keras + TF and some other less
> > popular libraries. But I am not completely satisfied so I am looking for
> > something new for my upcoming projects. So, I "investigate" MXNet now.
> >
> > 2)* I completely agree with Naveen*.
> >
> > 3) If you really want to see wide adoption of MXNet (like Spark, Kafka,
> > Flink, etc.), then tasks should be documented in some task tracker.
> > In this case everyone would be able to see the progress of the project,
> > understand which features, bug fixes are included into the next release,
> > intended to appear in near future. Developers, contributors, committers
> can
> > see the progress, the cadence of the project. Links to docs, Github PRs,
> > roadmaps, proposals, build results, other JIRAs are present in a JIRA
> > ticket so it's easy to navigate for everyone.
> > Github is suitable for code review and management. But it can't
> substitute
> > tracker system. Even small team will have hundreds of PRs, issues pretty
> > soon and chaos arises. Besides, there is no much fun (for "external"
> user)
> > in jumping from one Github PR to another trying to understand why & when
> &
> > in which commit something appeared.
> > I understand that MXNet was promoted into Apache incubator to enlarge
> > community, build ecosystem around it and for some other "commercial
> > interests". Without clear vision and understanding of project's status &
> > future, nobody will take MXNet into production or build MXNetT "plugin".
> >
> > 4)  "*There are 900+ issues, that once in a while gets closed without any
> > reason has happened already once*". It also happens with other
> Github-based
> > projects. For example, Presto committers go through list of issues once
> or
> > twice a year. And close vast majority of them with resolutions like
> "Won't
> > fix", "I don't like it", etc.
> >
> > 5) JIRA is very configurable, one does not have to jump from board to
> board
> > to edit / enter ticket info. I have Apache's JIRA account. And I can
> read,
> > add comments & files / patches to tickets, create tickets in some
> projects.
> > But privileges can be configured.
> >
> >
> > Timur
> >
> > On Fri, Jun 8, 2018 at 10:48 PM, Hen  wrote:
> >
> > > Are you saying only committers can make JIRA accounts?
> > >
> > > On Fri, Jun 8, 2018 at 2:41 PM Qing Lan  wrote:
> > >
> > > > + 0
> > > > Can we keep this optional? Not totally abandon or support.
> > > > Pros:
> > > > I used JIRA to track most of my PRs and can place them together at
> one
> > > > place. It also being helpful if we find some issues and group them
> > > together
> > > > as one case.
> > > > Cons:
> > > > Currently JIRA does not allow someone who is not contributor to file
> an
> > > > issue which makes first-time contributor hard to submit a PR.
> > > >
> > > > Thanks,
> > > > Qing
> > > >
> > > >
> > > > On 6/8/18, 2:27 PM, "Hao Jin"  wrote:
> > > >
> > > > +0.5
> > > > I'm an SDE working for MXNet Engine team at AWS and I've been
> using
> > > > JIRA
> > > > for nearly every single PR (28 out of 29 PR at this moment) I
> created
> > > > since
> > > > I joined the team 3 months ago. I wouldn't say it's a really bad
> > > > experience, but definitely not good.
> > > > I do agree that we need something like JIRA and extra effort
> other
> > > than
> > > > writing code to manage the project, but the current user
> experience
> > > > with
> > > > JIRA really has room for improvement.
> > > > The more important question for the community is that, is JIRA
> good
> > > for
> > > > attracting and retaining open source contributors? Such a user
> > > > experience
> > > > of JIRA could drive contributors away if we're really enforcing
> it.
> > > > In conclusion, I think the usage of JIRA should be of one's or
> team's
> > > > own
> > > > choice, if you do have the need to manage some development
> process
> > > > (like
> > > > our team), just continue to use it, but we should no longer
> enforce
> > > or
> > > > persuade anyone to use it.
> > > > I'm also attaching a typical workflow of mine using JIRA with
> sprint
> > > > management and story point tracking for a single task, I think
> > > > 

Re: Clojure Package

[YiZhi Liu]

Carin,

Thank you for the great work. I'll do the review. As I have no
expertise in Clojure, it will really help to have people from Clojure
community reviewing it as well :)

2018-06-08 14:22 GMT-07:00 Carin Meier :
> A couple of questions came up in regard to the PR and the current test
> suite state as well as the best way to review the PR since it is a new
> language binding.
>
> In regards to the Clojure test suite, most of the Scala test suite has been
> ported over with the goal of having comparable coverage. I can go ahead a
> put in a coverage tool to make that it a bit more transparent.
>
> For reviewing, I have a couple people in the Clojure community that are
> interested in collaborating in this project and I can ask them for help in
> reviewing the PR in some way if that is helpful too.
>
> I'm also open to other suggestions.
>
> Thanks,
> Carin
>
> On Fri, Jun 8, 2018 at 4:06 PM, Carin Meier  wrote:
>
>> Here is the PR https://github.com/apache/incubator-mxnet/pull/11205
>>
>> I've ported in the content from the external github repo (
>> https://github.com/gigasquid/clojure-mxnet), that has been tested by some
>> of the Clojure community, into the contrib directory.
>>
>> There is still lots more to do in relation to adding tests, benchmarks,
>> and increasing stability, but I thought this might be a good point to bring
>> it in initially so that the other work can be reviewed in smaller chunks.
>> I also would like to get other people involved in making it better, so I
>> thought that having the base package in there would be a good starting
>> point for collaboration.
>>
>> Feedback welcome.
>>
>> - Carin
>>
>>
>> On Tue, Jun 5, 2018 at 11:40 AM, Carin Meier  wrote:
>>
>>> Thanks everyone. I'll work on getting together a PR with your feedback
>>> and post it here.
>>>
>>> On Tue, Jun 5, 2018 at 4:05 AM, Chen HY  wrote:
>>>
 I would suggest using code generators in case upstream library adding the
 functions for arrays.
 It seems that cpp binding is using a code generator and works fine.

 2018-06-05 7:59 GMT+01:00 Naveen Swamy :

 > ~/mxnet/contrib/clojure-package good place for the code.
 >
 > the package name org.apache.mxnet.contrib.clojure ? do you need mxnet
 > again?
 >
 > I forgot to request to run some benchmarks and document. One of the
 reasons
 > users use MXNet is because of its performance and we want to ensure
 that we
 > maintain it across language bindings.
 >
 > Also invite your other clojure programmer buddies to the party :)
 >
 > Thanks, Naveen
 >
 >
 > On Mon, Jun 4, 2018 at 1:55 PM, Carin Meier 
 wrote:
 >
 > > Oh right. That's not a problem, I wonder if something like
 > >
 > > org.apache.mxnet.contrib/clojure-mxnet
 > >
 > > would work?
 > >
 > > If this seems like it is the right direction, we could work out the
 > details
 > > in a PR.
 > >
 > >
 > > On Mon, Jun 4, 2018 at 4:44 PM, Naveen Swamy 
 wrote:
 > >
 > > > I agree with your assessment that we shouldn't need the user to
 change
 > > > their code. I am not sure if we can release under
 > > org.apache.clojure-mxnet
 > > > we might have to stick with our primary group id org.apache.mxnet
 and
 > may
 > > > be create a sub-package under it? any creative ideas?
 > > >
 > > > On Mon, Jun 4, 2018 at 1:29 PM, Carin Meier 
 > > wrote:
 > > >
 > > > > Thanks for the feedback everyone.
 > > > >
 > > > > I agree on the contrib option. I think it's a great path forward
 and
 > > > would
 > > > > allow it time for feedback, contribution by others, and
 > stabilization.
 > > > >
 > > > > If I'm understanding correctly, that would mean putting the
 source
 > code
 > > > in:
 > > > > ~/mxnet/contrib/clojure-package
 > > > >
 > > > > and having the artifact jar named
 > > > > `org.apache.contrib.clojure-mxnet/clojure-mxnet`
 > > > >
 > > > > I would recommend not having the individual namespaces of the
 files
 > > have
 > > > > contrib embedded in them, so that if it graduates, users won't
 have
 > to
 > > > > change their code, only the dependency.
 > > > >
 > > > > Please let me know if this is correct or if there are any other
 > ideas.
 > > > >
 > > > > - Carin
 > > > >
 > > > >
 > > > >
 > > > >
 > > > > On Mon, Jun 4, 2018 at 4:03 PM, Naveen Swamy >>> >
 > > wrote:
 > > > >
 > > > > > I think that's a great idea to bring in under contrib and we
 can
 > also
 > > > get
 > > > > > user feedback
 > > > > >
 > > > > > > On Jun 4, 2018, at 12:44 PM, sandeep krishnamurthy <
 > > > > > sandeep.krishn...@gmail.com> wrote:
 > > > > > >
 > > > > > > Hi Carin,
 > > > > > >
 > > > > > > This is a commendable work. Thanks a lot for all the 

Re: Regarding 1.2.1 patch release

[Afrooze, Sina]

I would like the following two PRs to be added to the patch release ([1] is a 
regression fix for conv1D and [2] is a 20x performance improvement to slice 
operator).

1: https://github.com/apache/incubator-mxnet/pull/11194
2: https://github.com/apache/incubator-mxnet/pull/11124

Sina

On 6/8/18, 11:58 AM, "Anirudh"  wrote:

Hi all,

I have added the following PRs to the list :
MKLDNN:
https://github.com/apache/incubator-mxnet/pull/10706

RPI:
https://github.com/apache/incubator-mxnet/pull/11054

Docs/CI:
https://github.com/apache/incubator-mxnet/pull/10485
https://github.com/apache/incubator-mxnet/pull/10728
https://github.com/apache/incubator-mxnet/pull/10785
https://github.com/apache/incubator-mxnet/pull/11066

Anirudh


On Fri, Jun 8, 2018 at 9:16 AM, Marco de Abreu  wrote:

> Thanks a lot Aaron for addressing this in such a timely manner!
>
> It would definitely be great to see the raspberry build fixes in that
> branch since it's currently broken.
>
> -Marco
>
> Aaron Markham  schrieb am Fr., 8. Juni 2018,
> 18:10:
>
> > Hi Anirudh,
> > Marco brought my attention to CI failures on the 1.2.1 builds with 
regard
> > to docs. The failures are because the build scripts that are in the 
1.2.0
> > branch are out of date and have problems due to package updates that are
> > incompatible with each other.
> >
> > To fix this you'll need to bring all of the docs building scripts
> > up-to-date. There were a few updates prior to #10485, so if those are
> > missing from 1.2.0, they might need to be included too. (#10270,#10010,
> > #9878)
> >
> > Please use this major update to docs building:
> > https://github.com/apache/incubator-mxnet/pull/10485
> >
> > These update docs to reflect the changes:
> > https://github.com/apache/incubator-mxnet/pull/10728
> > https://github.com/apache/incubator-mxnet/pull/10785
> >
> > This updates the Jenkinsfile to secure nodes:
> > https://github.com/apache/incubator-mxnet/pull/11066
> >
> > Please let me know if you have any questions.
> >
> > Cheers,
> > Aaron
> >
> > On Fri, Jun 8, 2018 at 6:34 AM, Anton Chernov 
> wrote:
> >
> > > I would like to propose [1] as an important fix for RaspberryPi's for
> the
> > > 1.2 patch release.
> > >
> > > -- Anton
> > >
> > > [1] https://github.com/apache/incubator-mxnet/pull/11054
> > >
> > > 2018-06-08 1:44 GMT+02:00 Zheng, Da :
> > >
> > > > Hello Anirudh,
> > > >
> > > > There is a test (test_hybrid_multi_context) for
> > > https://github.com/apache/
> > > > incubator-mxnet/pull/10706
> > > > It's also tested by the C++ unit tests in https://github.com/apache/
> > > > incubator-mxnet/pull/10979
> > > > https://github.com/apache/incubator-mxnet/pull/10979/files#diff-
> > > > 8118d4fd8d897a9177f48257a466ea13R435
> > > >
> > > > Best,
> > > > Da
> > > >
> > > > On 6/7/18, 3:37 PM, "Anirudh"  wrote:
> > > >
> > > > Hi Da,
> > > >
> > > > Can you please open a PR to the 1.2 branch with the following 
PRs
> > > > mentioned
> > > > by you and Tao cherry picked onto release branch.
> > > >
> > > > https://github.com/apache/incubator-mxnet/pull/10979
> > > > https://github.com/apache/incubator-mxnet/pull/10731
> > > > https://github.com/apache/incubator-mxnet/pull/10651
> > > > https://github.com/apache/incubator-mxnet/pull/10624
> > > > https://github.com/apache/incubator-mxnet/pull/10619
> > > > https://github.com/apache/incubator-mxnet/pull/10616
> > > > https://github.com/apache/incubator-mxnet/pull/10918
> > > > https://github.com/apache/incubator-mxnet/pull/10613
> > > >
> > > > I am a little concerned about the below two PRs since they don't
> > have
> > > > enough tests:
> > > > https://github.com/apache/incubator-mxnet/pull/10706
> > > > https://github.com/apache/incubator-mxnet/pull/10810
> > > >
> > > > 
> > > > Can you please talk about the test coverage of these two PRs.
> > > >
> > > > Hi Tao,
> > > >
> > > > To answer your question about the criteria for choosing PRs for
> > patch
> > > > release: I think we haven't done patch release many times before
> > and
> > > we
> > > > don't have a clear set of criteria on what can go into the patch
> > > > release.
> > > > The main intention of doing patch release is to fix the
> > undocumented
> > > > backwards incompatible change from 1.1. Along with this critical
> > > fixes
> > > > should also be pushed out. AFAIK, The "critical" here is not
> > 

Re: Vote to stop using JIRA

[Eric Xie]

Github has many project management tools. Any of them would be a better choice 
than JIRA.

Thanks,
Eric

On 2018/06/09 00:02:55, Timur Shenkao  wrote: 
> Hello guys!
> Let me add five cents step-by-step. Some kind of "external viewpoint" (I
> don't work in Amazon or Intel).
> 1) Thanks a lot of for interesting product / framework like MXNet.
> Currently, I use pretty standard DL stack: Keras + TF and some other less
> popular libraries. But I am not completely satisfied so I am looking for
> something new for my upcoming projects. So, I "investigate" MXNet now.
> 
> 2)* I completely agree with Naveen*.
> 
> 3) If you really want to see wide adoption of MXNet (like Spark, Kafka,
> Flink, etc.), then tasks should be documented in some task tracker.
> In this case everyone would be able to see the progress of the project,
> understand which features, bug fixes are included into the next release,
> intended to appear in near future. Developers, contributors, committers can
> see the progress, the cadence of the project. Links to docs, Github PRs,
> roadmaps, proposals, build results, other JIRAs are present in a JIRA
> ticket so it's easy to navigate for everyone.
> Github is suitable for code review and management. But it can't substitute
> tracker system. Even small team will have hundreds of PRs, issues pretty
> soon and chaos arises. Besides, there is no much fun (for "external" user)
> in jumping from one Github PR to another trying to understand why & when &
> in which commit something appeared.
> I understand that MXNet was promoted into Apache incubator to enlarge
> community, build ecosystem around it and for some other "commercial
> interests". Without clear vision and understanding of project's status &
> future, nobody will take MXNet into production or build MXNetT "plugin".
> 
> 4)  "*There are 900+ issues, that once in a while gets closed without any
> reason has happened already once*". It also happens with other Github-based
> projects. For example, Presto committers go through list of issues once or
> twice a year. And close vast majority of them with resolutions like "Won't
> fix", "I don't like it", etc.
> 
> 5) JIRA is very configurable, one does not have to jump from board to board
> to edit / enter ticket info. I have Apache's JIRA account. And I can read,
> add comments & files / patches to tickets, create tickets in some projects.
> But privileges can be configured.
> 
> 
> Timur
> 
> On Fri, Jun 8, 2018 at 10:48 PM, Hen  wrote:
> 
> > Are you saying only committers can make JIRA accounts?
> >
> > On Fri, Jun 8, 2018 at 2:41 PM Qing Lan  wrote:
> >
> > > + 0
> > > Can we keep this optional? Not totally abandon or support.
> > > Pros:
> > > I used JIRA to track most of my PRs and can place them together at one
> > > place. It also being helpful if we find some issues and group them
> > together
> > > as one case.
> > > Cons:
> > > Currently JIRA does not allow someone who is not contributor to file an
> > > issue which makes first-time contributor hard to submit a PR.
> > >
> > > Thanks,
> > > Qing
> > >
> > >
> > > On 6/8/18, 2:27 PM, "Hao Jin"  wrote:
> > >
> > > +0.5
> > > I'm an SDE working for MXNet Engine team at AWS and I've been using
> > > JIRA
> > > for nearly every single PR (28 out of 29 PR at this moment) I created
> > > since
> > > I joined the team 3 months ago. I wouldn't say it's a really bad
> > > experience, but definitely not good.
> > > I do agree that we need something like JIRA and extra effort other
> > than
> > > writing code to manage the project, but the current user experience
> > > with
> > > JIRA really has room for improvement.
> > > The more important question for the community is that, is JIRA good
> > for
> > > attracting and retaining open source contributors? Such a user
> > > experience
> > > of JIRA could drive contributors away if we're really enforcing it.
> > > In conclusion, I think the usage of JIRA should be of one's or team's
> > > own
> > > choice, if you do have the need to manage some development process
> > > (like
> > > our team), just continue to use it, but we should no longer enforce
> > or
> > > persuade anyone to use it.
> > > I'm also attaching a typical workflow of mine using JIRA with sprint
> > > management and story point tracking for a single task, I think
> > > everyone who
> > > has used JIRA so far would share part of my experience.
> > > Thanks,
> > > Hao
> > >
> > > Appendix: what I need to do when I'm working on a task with JIRA:
> > > 1. Before I start working on something:
> > > 1) create a JIRA ticket for that, choose the correct type and
> > > define a
> > > proper name for it
> > > 2) go to backlog page to add it to a sprint if you want to use
> > the
> > > sprint management.
> > > 3) go to sprint management page to assign story point value if
> > you
> > > need
> > > the functionality (we 

Re: Vote to stop using JIRA

[Timur Shenkao]

Hello guys!
Let me add five cents step-by-step. Some kind of "external viewpoint" (I
don't work in Amazon or Intel).
1) Thanks a lot of for interesting product / framework like MXNet.
Currently, I use pretty standard DL stack: Keras + TF and some other less
popular libraries. But I am not completely satisfied so I am looking for
something new for my upcoming projects. So, I "investigate" MXNet now.

2)* I completely agree with Naveen*.

3) If you really want to see wide adoption of MXNet (like Spark, Kafka,
Flink, etc.), then tasks should be documented in some task tracker.
In this case everyone would be able to see the progress of the project,
understand which features, bug fixes are included into the next release,
intended to appear in near future. Developers, contributors, committers can
see the progress, the cadence of the project. Links to docs, Github PRs,
roadmaps, proposals, build results, other JIRAs are present in a JIRA
ticket so it's easy to navigate for everyone.
Github is suitable for code review and management. But it can't substitute
tracker system. Even small team will have hundreds of PRs, issues pretty
soon and chaos arises. Besides, there is no much fun (for "external" user)
in jumping from one Github PR to another trying to understand why & when &
in which commit something appeared.
I understand that MXNet was promoted into Apache incubator to enlarge
community, build ecosystem around it and for some other "commercial
interests". Without clear vision and understanding of project's status &
future, nobody will take MXNet into production or build MXNetT "plugin".

4)  "*There are 900+ issues, that once in a while gets closed without any
reason has happened already once*". It also happens with other Github-based
projects. For example, Presto committers go through list of issues once or
twice a year. And close vast majority of them with resolutions like "Won't
fix", "I don't like it", etc.

5) JIRA is very configurable, one does not have to jump from board to board
to edit / enter ticket info. I have Apache's JIRA account. And I can read,
add comments & files / patches to tickets, create tickets in some projects.
But privileges can be configured.


Timur

On Fri, Jun 8, 2018 at 10:48 PM, Hen  wrote:

> Are you saying only committers can make JIRA accounts?
>
> On Fri, Jun 8, 2018 at 2:41 PM Qing Lan  wrote:
>
> > + 0
> > Can we keep this optional? Not totally abandon or support.
> > Pros:
> > I used JIRA to track most of my PRs and can place them together at one
> > place. It also being helpful if we find some issues and group them
> together
> > as one case.
> > Cons:
> > Currently JIRA does not allow someone who is not contributor to file an
> > issue which makes first-time contributor hard to submit a PR.
> >
> > Thanks,
> > Qing
> >
> >
> > On 6/8/18, 2:27 PM, "Hao Jin"  wrote:
> >
> > +0.5
> > I'm an SDE working for MXNet Engine team at AWS and I've been using
> > JIRA
> > for nearly every single PR (28 out of 29 PR at this moment) I created
> > since
> > I joined the team 3 months ago. I wouldn't say it's a really bad
> > experience, but definitely not good.
> > I do agree that we need something like JIRA and extra effort other
> than
> > writing code to manage the project, but the current user experience
> > with
> > JIRA really has room for improvement.
> > The more important question for the community is that, is JIRA good
> for
> > attracting and retaining open source contributors? Such a user
> > experience
> > of JIRA could drive contributors away if we're really enforcing it.
> > In conclusion, I think the usage of JIRA should be of one's or team's
> > own
> > choice, if you do have the need to manage some development process
> > (like
> > our team), just continue to use it, but we should no longer enforce
> or
> > persuade anyone to use it.
> > I'm also attaching a typical workflow of mine using JIRA with sprint
> > management and story point tracking for a single task, I think
> > everyone who
> > has used JIRA so far would share part of my experience.
> > Thanks,
> > Hao
> >
> > Appendix: what I need to do when I'm working on a task with JIRA:
> > 1. Before I start working on something:
> > 1) create a JIRA ticket for that, choose the correct type and
> > define a
> > proper name for it
> > 2) go to backlog page to add it to a sprint if you want to use
> the
> > sprint management.
> > 3) go to sprint management page to assign story point value if
> you
> > need
> > the functionality (we recently started doing that)
> > 2. When I start working on the task:
> > 1) dig my ticket up (on the sprint page or backlog page or search
> > for
> > it)
> > 2) click "open and start progress" to move it to "IN PROGRESS"
> > phase.
> > 3. When I finish the code, for every new PR I'll have to:
> > 1) dig my ticket up
> > 2) 

Re: Vote to stop using JIRA

[Hen]

Are you saying only committers can make JIRA accounts?

On Fri, Jun 8, 2018 at 2:41 PM Qing Lan  wrote:

> + 0
> Can we keep this optional? Not totally abandon or support.
> Pros:
> I used JIRA to track most of my PRs and can place them together at one
> place. It also being helpful if we find some issues and group them together
> as one case.
> Cons:
> Currently JIRA does not allow someone who is not contributor to file an
> issue which makes first-time contributor hard to submit a PR.
>
> Thanks,
> Qing
>
>
> On 6/8/18, 2:27 PM, "Hao Jin"  wrote:
>
> +0.5
> I'm an SDE working for MXNet Engine team at AWS and I've been using
> JIRA
> for nearly every single PR (28 out of 29 PR at this moment) I created
> since
> I joined the team 3 months ago. I wouldn't say it's a really bad
> experience, but definitely not good.
> I do agree that we need something like JIRA and extra effort other than
> writing code to manage the project, but the current user experience
> with
> JIRA really has room for improvement.
> The more important question for the community is that, is JIRA good for
> attracting and retaining open source contributors? Such a user
> experience
> of JIRA could drive contributors away if we're really enforcing it.
> In conclusion, I think the usage of JIRA should be of one's or team's
> own
> choice, if you do have the need to manage some development process
> (like
> our team), just continue to use it, but we should no longer enforce or
> persuade anyone to use it.
> I'm also attaching a typical workflow of mine using JIRA with sprint
> management and story point tracking for a single task, I think
> everyone who
> has used JIRA so far would share part of my experience.
> Thanks,
> Hao
>
> Appendix: what I need to do when I'm working on a task with JIRA:
> 1. Before I start working on something:
> 1) create a JIRA ticket for that, choose the correct type and
> define a
> proper name for it
> 2) go to backlog page to add it to a sprint if you want to use the
> sprint management.
> 3) go to sprint management page to assign story point value if you
> need
> the functionality (we recently started doing that)
> 2. When I start working on the task:
> 1) dig my ticket up (on the sprint page or backlog page or search
> for
> it)
> 2) click "open and start progress" to move it to "IN PROGRESS"
> phase.
> 3. When I finish the code, for every new PR I'll have to:
> 1) dig my ticket up
> 2) copy the ticket number so that I can add it to the PR title
> 3) an extra click to move the ticket to REVIEW phase
> 4) create a PR on github, paste the "MXNET-xxx" I just copied
> inside an
> extra pair of square brackets "[]"
> 5) still need to refer the related github issue in the PR if I'm
> solving one of them
> 4. For every code review or comment I receive on the new PR:
> 1) the JIRA bot logs 10 mins on the ticket no matter what kind of
> comment it is
> 2) JIRA sends me an email for every single one of such logs (so if
> you
> receive 10 code review comments in a single code review you get 10
> emails,
> my highest record was 17, while github would bundle all of them in
> only 1
> mail)
> 5. After the PR is merged I get an email from JIRA saying this is
> merged
> (for the bot, merge is like another comment on the PR) but I still
> have to:
> 1) dig my ticket up
> 2) manually move it to DONE phase (bot does not do that
> automatically).
> 6. The task is considered finished at this point, but any new comments
> on
> the PR will trigger the bot once again to log 10 mins on your ticket
> together with another email coming to your mailbox, while github is
> already
> sending an email for that.
>
> On Fri, Jun 8, 2018 at 2:23 PM, Naveen Swamy 
> wrote:
>
> > Eric/Mu/Tianqi,
> >
> > A couple of contributors  have used JIRA for the Scala project --
> this is
> > the first time, so there is some learning for us, We started off
> with a
> > design proposal, followed by a call for contribution. We kept our
> progress
> > open on the dev list and we found one contributor to help us during
> > debugging/testing/maven package creation and also one of them is
> working on
> > the Memory allocation issue in Scala not as a part of their day job;
> This
> > is where I find value in managing the project features on JIRA,
> designs on
> > the public wiki, etc.,. I am not claiming that this is perfect, this
> is a
> > WIP and as a community we should give it a chance and try it out.
> >
> > I don't think most of us here have even looked at JIRA.
> >
> > P.S: I am traveling, my response will be delayed.
> >
> > -Naveen
> >
> >
> > On Fri, Jun 8, 2018 at 12:34 PM, Anirudh 
> wrote:
> 

Re: Vote to stop using JIRA

[Qing Lan]

+ 0
Can we keep this optional? Not totally abandon or support. 
Pros:
I used JIRA to track most of my PRs and can place them together at one place. 
It also being helpful if we find some issues and group them together as one 
case. 
Cons:
Currently JIRA does not allow someone who is not contributor to file an issue 
which makes first-time contributor hard to submit a PR.

Thanks,
Qing


On 6/8/18, 2:27 PM, "Hao Jin"  wrote:

+0.5
I'm an SDE working for MXNet Engine team at AWS and I've been using JIRA
for nearly every single PR (28 out of 29 PR at this moment) I created since
I joined the team 3 months ago. I wouldn't say it's a really bad
experience, but definitely not good.
I do agree that we need something like JIRA and extra effort other than
writing code to manage the project, but the current user experience with
JIRA really has room for improvement.
The more important question for the community is that, is JIRA good for
attracting and retaining open source contributors? Such a user experience
of JIRA could drive contributors away if we're really enforcing it.
In conclusion, I think the usage of JIRA should be of one's or team's own
choice, if you do have the need to manage some development process (like
our team), just continue to use it, but we should no longer enforce or
persuade anyone to use it.
I'm also attaching a typical workflow of mine using JIRA with sprint
management and story point tracking for a single task, I think everyone who
has used JIRA so far would share part of my experience.
Thanks,
Hao

Appendix: what I need to do when I'm working on a task with JIRA:
1. Before I start working on something:
1) create a JIRA ticket for that, choose the correct type and define a
proper name for it
2) go to backlog page to add it to a sprint if you want to use the
sprint management.
3) go to sprint management page to assign story point value if you need
the functionality (we recently started doing that)
2. When I start working on the task:
1) dig my ticket up (on the sprint page or backlog page or search for
it)
2) click "open and start progress" to move it to "IN PROGRESS" phase.
3. When I finish the code, for every new PR I'll have to:
1) dig my ticket up
2) copy the ticket number so that I can add it to the PR title
3) an extra click to move the ticket to REVIEW phase
4) create a PR on github, paste the "MXNET-xxx" I just copied inside an
extra pair of square brackets "[]"
5) still need to refer the related github issue in the PR if I'm
solving one of them
4. For every code review or comment I receive on the new PR:
1) the JIRA bot logs 10 mins on the ticket no matter what kind of
comment it is
2) JIRA sends me an email for every single one of such logs (so if you
receive 10 code review comments in a single code review you get 10 emails,
my highest record was 17, while github would bundle all of them in only 1
mail)
5. After the PR is merged I get an email from JIRA saying this is merged
(for the bot, merge is like another comment on the PR) but I still have to:
1) dig my ticket up
2) manually move it to DONE phase (bot does not do that automatically).
6. The task is considered finished at this point, but any new comments on
the PR will trigger the bot once again to log 10 mins on your ticket
together with another email coming to your mailbox, while github is already
sending an email for that.

On Fri, Jun 8, 2018 at 2:23 PM, Naveen Swamy  wrote:

> Eric/Mu/Tianqi,
>
> A couple of contributors  have used JIRA for the Scala project -- this is
> the first time, so there is some learning for us, We started off with a
> design proposal, followed by a call for contribution. We kept our progress
> open on the dev list and we found one contributor to help us during
> debugging/testing/maven package creation and also one of them is working 
on
> the Memory allocation issue in Scala not as a part of their day job; This
> is where I find value in managing the project features on JIRA, designs on
> the public wiki, etc.,. I am not claiming that this is perfect, this is a
> WIP and as a community we should give it a chance and try it out.
>
> I don't think most of us here have even looked at JIRA.
>
> P.S: I am traveling, my response will be delayed.
>
> -Naveen
>
>
> On Fri, Jun 8, 2018 at 12:34 PM, Anirudh  wrote:
>
> > Hi,
> >
> > I am not a big fan of JIRA either. But I would like to raise this issue
> of
> > committing to a decision after a VOTE has passed. I saw in PRs that 
there
> > was a disregard for JIRA and ignoring requests on PRs to link to JIRA.
> > Because of this, JIRA was not given a fair 

Re: Vote to stop using JIRA

[Naveen Swamy]

Eric/Mu/Tianqi,

A couple of contributors  have used JIRA for the Scala project -- this is
the first time, so there is some learning for us, We started off with a
design proposal, followed by a call for contribution. We kept our progress
open on the dev list and we found one contributor to help us during
debugging/testing/maven package creation and also one of them is working on
the Memory allocation issue in Scala not as a part of their day job; This
is where I find value in managing the project features on JIRA, designs on
the public wiki, etc.,. I am not claiming that this is perfect, this is a
WIP and as a community we should give it a chance and try it out.

I don't think most of us here have even looked at JIRA.

P.S: I am traveling, my response will be delayed.

-Naveen


On Fri, Jun 8, 2018 at 12:34 PM, Anirudh  wrote:

> Hi,
>
> I am not a big fan of JIRA either. But I would like to raise this issue of
> committing to a decision after a VOTE has passed. I saw in PRs that there
> was a disregard for JIRA and ignoring requests on PRs to link to JIRA.
> Because of this, JIRA was not given a fair chance to be tried out as a
> project management tool and eventually hardly being used. If we don't work
> on this as a community, VOTEs also tend to loose their meaning.
>
> Anirudh
>
>
>
> On Fri, Jun 8, 2018 at 11:00 AM, Eric Xie  wrote:
>
> > I think the number of issues become less of a problem if we label them
> > timely, which is already improving.
> >
> > Thanks,
> > Eric
> >
> > On 2018/06/08 17:55:28, Tianqi Chen  wrote:
> > > I would suggest we have a separate discussion issue about transparency.
> > > First of all, I agree that transparency is important.
> > >
> > > This can be achieved by public roadmaps, RFCs, that do not have
> > > particularly tie to JIRA or github issues. Having a clear guideline on
> > that
> > > would be great, and it is great to see more RFCs in the dev list.
> > >
> > > In terms of issues themselves, I think one problem we are facing is
> > > overflowing amount of issues. One way to minimize this would be to
> > redirect
> > > more questions to forums, and only keep issues that are actionable and
> > > encourage the committers who opens the issue to fix them timely.
> > >
> > > Tianqi
> > >
> > > On Fri, Jun 8, 2018 at 10:35 AM, Naveen Swamy 
> > wrote:
> > >
> > > > -1 (binding)
> > > >
> > > > The very reason why JIRA was suggested so that the project is more
> > open on
> > > > the features that are worked on. There are 900+ issues, that once in
> a
> > > > while gets closed without any reason has happened already once.
> > > > There is already integration with GitHub PRs, please check it out.
> > > >
> > > > Features pop into the code-base without any discussion, they also get
> > > > removed without any discussion. PRs come in when the feature is
> > complete,
> > > > not giving others  opportunity to understand/contribute or have a
> say.
> > > >
> > > > If this project embraces the true Apache spirit and follow successful
> > > > practices we could get lot more people excited about this project.
> Many
> > > > successful Apache projects use JIRA, look at Apache Spark which has
> > 1250+
> > > > contributors and built a community of 500,000 people around the
> world.
> > > >
> > > > -Naveen
> > > >
> > > >
> > > > On Fri, Jun 8, 2018 at 10:27 AM, Eric Xie  wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > Since all of MXNet's development happens on Github, I think it's
> > > > > sufficient to use Github Issues and Github Projects for tracking.
> > There
> > > > are
> > > > > also many other plugins you can add to Github if issues and
> projects
> > are
> > > > > not enough.
> > > > >
> > > > > It's very easy to cross reference PRs and issues for tracking. In
> > > > > comparison, JIRA is an outdated system with very little features
> and
> > no
> > > > > integration with Github. I think using it achieves nothing but
> > additional
> > > > > overhead.
> > > > >
> > > > > Thanks,
> > > > > Eric
> > > > >
> > > >
> > >
> >
>

Re: Clojure Package

[Carin Meier]

A couple of questions came up in regard to the PR and the current test
suite state as well as the best way to review the PR since it is a new
language binding.

In regards to the Clojure test suite, most of the Scala test suite has been
ported over with the goal of having comparable coverage. I can go ahead a
put in a coverage tool to make that it a bit more transparent.

For reviewing, I have a couple people in the Clojure community that are
interested in collaborating in this project and I can ask them for help in
reviewing the PR in some way if that is helpful too.

I'm also open to other suggestions.

Thanks,
Carin

On Fri, Jun 8, 2018 at 4:06 PM, Carin Meier  wrote:

> Here is the PR https://github.com/apache/incubator-mxnet/pull/11205
>
> I've ported in the content from the external github repo (
> https://github.com/gigasquid/clojure-mxnet), that has been tested by some
> of the Clojure community, into the contrib directory.
>
> There is still lots more to do in relation to adding tests, benchmarks,
> and increasing stability, but I thought this might be a good point to bring
> it in initially so that the other work can be reviewed in smaller chunks.
> I also would like to get other people involved in making it better, so I
> thought that having the base package in there would be a good starting
> point for collaboration.
>
> Feedback welcome.
>
> - Carin
>
>
> On Tue, Jun 5, 2018 at 11:40 AM, Carin Meier  wrote:
>
>> Thanks everyone. I'll work on getting together a PR with your feedback
>> and post it here.
>>
>> On Tue, Jun 5, 2018 at 4:05 AM, Chen HY  wrote:
>>
>>> I would suggest using code generators in case upstream library adding the
>>> functions for arrays.
>>> It seems that cpp binding is using a code generator and works fine.
>>>
>>> 2018-06-05 7:59 GMT+01:00 Naveen Swamy :
>>>
>>> > ~/mxnet/contrib/clojure-package good place for the code.
>>> >
>>> > the package name org.apache.mxnet.contrib.clojure ? do you need mxnet
>>> > again?
>>> >
>>> > I forgot to request to run some benchmarks and document. One of the
>>> reasons
>>> > users use MXNet is because of its performance and we want to ensure
>>> that we
>>> > maintain it across language bindings.
>>> >
>>> > Also invite your other clojure programmer buddies to the party :)
>>> >
>>> > Thanks, Naveen
>>> >
>>> >
>>> > On Mon, Jun 4, 2018 at 1:55 PM, Carin Meier 
>>> wrote:
>>> >
>>> > > Oh right. That's not a problem, I wonder if something like
>>> > >
>>> > > org.apache.mxnet.contrib/clojure-mxnet
>>> > >
>>> > > would work?
>>> > >
>>> > > If this seems like it is the right direction, we could work out the
>>> > details
>>> > > in a PR.
>>> > >
>>> > >
>>> > > On Mon, Jun 4, 2018 at 4:44 PM, Naveen Swamy 
>>> wrote:
>>> > >
>>> > > > I agree with your assessment that we shouldn't need the user to
>>> change
>>> > > > their code. I am not sure if we can release under
>>> > > org.apache.clojure-mxnet
>>> > > > we might have to stick with our primary group id org.apache.mxnet
>>> and
>>> > may
>>> > > > be create a sub-package under it? any creative ideas?
>>> > > >
>>> > > > On Mon, Jun 4, 2018 at 1:29 PM, Carin Meier 
>>> > > wrote:
>>> > > >
>>> > > > > Thanks for the feedback everyone.
>>> > > > >
>>> > > > > I agree on the contrib option. I think it's a great path forward
>>> and
>>> > > > would
>>> > > > > allow it time for feedback, contribution by others, and
>>> > stabilization.
>>> > > > >
>>> > > > > If I'm understanding correctly, that would mean putting the
>>> source
>>> > code
>>> > > > in:
>>> > > > > ~/mxnet/contrib/clojure-package
>>> > > > >
>>> > > > > and having the artifact jar named
>>> > > > > `org.apache.contrib.clojure-mxnet/clojure-mxnet`
>>> > > > >
>>> > > > > I would recommend not having the individual namespaces of the
>>> files
>>> > > have
>>> > > > > contrib embedded in them, so that if it graduates, users won't
>>> have
>>> > to
>>> > > > > change their code, only the dependency.
>>> > > > >
>>> > > > > Please let me know if this is correct or if there are any other
>>> > ideas.
>>> > > > >
>>> > > > > - Carin
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > > On Mon, Jun 4, 2018 at 4:03 PM, Naveen Swamy >> >
>>> > > wrote:
>>> > > > >
>>> > > > > > I think that's a great idea to bring in under contrib and we
>>> can
>>> > also
>>> > > > get
>>> > > > > > user feedback
>>> > > > > >
>>> > > > > > > On Jun 4, 2018, at 12:44 PM, sandeep krishnamurthy <
>>> > > > > > sandeep.krishn...@gmail.com> wrote:
>>> > > > > > >
>>> > > > > > > Hi Carin,
>>> > > > > > >
>>> > > > > > > This is a commendable work. Thanks a lot for all the hard and
>>> > smart
>>> > > > > work
>>> > > > > > > you have put behind this :-) I think this will be a great
>>> value
>>> > > > > addition.
>>> > > > > > >
>>> > > > > > > If people are not sure about usage, can I suggest this
>>> awesome
>>> > work
>>> > > > to
>>> > > > > be
>>> > > > > > > brought in "contrib" package? Invite and build the community
>>> > around
>>> 

About Becoming a Committer

[Sheng Zha]

Hi,

There have been a couple of offline inquiries from contributors about
becoming a committer. From those inquiries, it seems that there’s confusion
in our community about how to become a committer, so I’d like to take this
opportunity to clarify.

The guideline about becoming a committer can be found at
https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer. The
gist of the guideline is that, like any other Apache project, MXNet
committers are invited by existing committers based on merit. The existing
committers look for sustained, high quality contribution and community
involvement among project contributors. When a candidate is spotted, this
contributor will be nominated and voted among PMC members, and if all goes
well, this contributor will receive an invitation to join as a committer
and PMC member.

Note that such discussion and decision happens in private among existing
PMC members and mentors through consensus, and information regarding what
happened in this process will always remain private, so as to rid the
influence of different interest groups. PMC members will not ask
contributors for committer application, nor will they accept one. Except
the aforementioned PMC members consensus process, any other process by any
organization under any circumstances will not be recognized.

I hope that you find the above clarification helpful. If you have further
question on this topic feel free to ask.

Sheng

Re: Clojure Package

[Carin Meier]

Here is the PR https://github.com/apache/incubator-mxnet/pull/11205

I've ported in the content from the external github repo (
https://github.com/gigasquid/clojure-mxnet), that has been tested by some
of the Clojure community, into the contrib directory.

There is still lots more to do in relation to adding tests, benchmarks, and
increasing stability, but I thought this might be a good point to bring it
in initially so that the other work can be reviewed in smaller chunks.
I also would like to get other people involved in making it better, so I
thought that having the base package in there would be a good starting
point for collaboration.

Feedback welcome.

- Carin


On Tue, Jun 5, 2018 at 11:40 AM, Carin Meier  wrote:

> Thanks everyone. I'll work on getting together a PR with your feedback and
> post it here.
>
> On Tue, Jun 5, 2018 at 4:05 AM, Chen HY  wrote:
>
>> I would suggest using code generators in case upstream library adding the
>> functions for arrays.
>> It seems that cpp binding is using a code generator and works fine.
>>
>> 2018-06-05 7:59 GMT+01:00 Naveen Swamy :
>>
>> > ~/mxnet/contrib/clojure-package good place for the code.
>> >
>> > the package name org.apache.mxnet.contrib.clojure ? do you need mxnet
>> > again?
>> >
>> > I forgot to request to run some benchmarks and document. One of the
>> reasons
>> > users use MXNet is because of its performance and we want to ensure
>> that we
>> > maintain it across language bindings.
>> >
>> > Also invite your other clojure programmer buddies to the party :)
>> >
>> > Thanks, Naveen
>> >
>> >
>> > On Mon, Jun 4, 2018 at 1:55 PM, Carin Meier 
>> wrote:
>> >
>> > > Oh right. That's not a problem, I wonder if something like
>> > >
>> > > org.apache.mxnet.contrib/clojure-mxnet
>> > >
>> > > would work?
>> > >
>> > > If this seems like it is the right direction, we could work out the
>> > details
>> > > in a PR.
>> > >
>> > >
>> > > On Mon, Jun 4, 2018 at 4:44 PM, Naveen Swamy 
>> wrote:
>> > >
>> > > > I agree with your assessment that we shouldn't need the user to
>> change
>> > > > their code. I am not sure if we can release under
>> > > org.apache.clojure-mxnet
>> > > > we might have to stick with our primary group id org.apache.mxnet
>> and
>> > may
>> > > > be create a sub-package under it? any creative ideas?
>> > > >
>> > > > On Mon, Jun 4, 2018 at 1:29 PM, Carin Meier 
>> > > wrote:
>> > > >
>> > > > > Thanks for the feedback everyone.
>> > > > >
>> > > > > I agree on the contrib option. I think it's a great path forward
>> and
>> > > > would
>> > > > > allow it time for feedback, contribution by others, and
>> > stabilization.
>> > > > >
>> > > > > If I'm understanding correctly, that would mean putting the source
>> > code
>> > > > in:
>> > > > > ~/mxnet/contrib/clojure-package
>> > > > >
>> > > > > and having the artifact jar named
>> > > > > `org.apache.contrib.clojure-mxnet/clojure-mxnet`
>> > > > >
>> > > > > I would recommend not having the individual namespaces of the
>> files
>> > > have
>> > > > > contrib embedded in them, so that if it graduates, users won't
>> have
>> > to
>> > > > > change their code, only the dependency.
>> > > > >
>> > > > > Please let me know if this is correct or if there are any other
>> > ideas.
>> > > > >
>> > > > > - Carin
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > On Mon, Jun 4, 2018 at 4:03 PM, Naveen Swamy 
>> > > wrote:
>> > > > >
>> > > > > > I think that's a great idea to bring in under contrib and we can
>> > also
>> > > > get
>> > > > > > user feedback
>> > > > > >
>> > > > > > > On Jun 4, 2018, at 12:44 PM, sandeep krishnamurthy <
>> > > > > > sandeep.krishn...@gmail.com> wrote:
>> > > > > > >
>> > > > > > > Hi Carin,
>> > > > > > >
>> > > > > > > This is a commendable work. Thanks a lot for all the hard and
>> > smart
>> > > > > work
>> > > > > > > you have put behind this :-) I think this will be a great
>> value
>> > > > > addition.
>> > > > > > >
>> > > > > > > If people are not sure about usage, can I suggest this awesome
>> > work
>> > > > to
>> > > > > be
>> > > > > > > brought in "contrib" package? Invite and build the community
>> > around
>> > > > > > > Clojure, stabilize and increase the coverage, and based on
>> usage
>> > > and
>> > > > > > > development, graduate it to main stable support from contrib.
>> > > > > > >
>> > > > > > > Suggestions and thoughts?
>> > > > > > >
>> > > > > > > Best,
>> > > > > > > Sandeep
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > On Mon, Jun 4, 2018 at 12:27 PM, Ivan Serdyuk <
>> > > > > > local.tourist.k...@gmail.com>
>> > > > > > > wrote:
>> > > > > > >
>> > > > > > >> Hello everyone.
>> > > > > > >>
>> > > > > > >> A small comment, about Scala API: main commiters are hardly
>> > > > available,
>> > > > > > as
>> > > > > > >> for today.
>> > > > > > >>
>> > > > > > >> As for Clojure - I might suggest that it might be possible to
>> > > > enlight
>> > > > > > >> future work, for that package, for Clojure developers.
>> > 

Re: Vote to stop using JIRA

[Anirudh]

Hi,

I am not a big fan of JIRA either. But I would like to raise this issue of
committing to a decision after a VOTE has passed. I saw in PRs that there
was a disregard for JIRA and ignoring requests on PRs to link to JIRA.
Because of this, JIRA was not given a fair chance to be tried out as a
project management tool and eventually hardly being used. If we don't work
on this as a community, VOTEs also tend to loose their meaning.

Anirudh



On Fri, Jun 8, 2018 at 11:00 AM, Eric Xie  wrote:

> I think the number of issues become less of a problem if we label them
> timely, which is already improving.
>
> Thanks,
> Eric
>
> On 2018/06/08 17:55:28, Tianqi Chen  wrote:
> > I would suggest we have a separate discussion issue about transparency.
> > First of all, I agree that transparency is important.
> >
> > This can be achieved by public roadmaps, RFCs, that do not have
> > particularly tie to JIRA or github issues. Having a clear guideline on
> that
> > would be great, and it is great to see more RFCs in the dev list.
> >
> > In terms of issues themselves, I think one problem we are facing is
> > overflowing amount of issues. One way to minimize this would be to
> redirect
> > more questions to forums, and only keep issues that are actionable and
> > encourage the committers who opens the issue to fix them timely.
> >
> > Tianqi
> >
> > On Fri, Jun 8, 2018 at 10:35 AM, Naveen Swamy 
> wrote:
> >
> > > -1 (binding)
> > >
> > > The very reason why JIRA was suggested so that the project is more
> open on
> > > the features that are worked on. There are 900+ issues, that once in a
> > > while gets closed without any reason has happened already once.
> > > There is already integration with GitHub PRs, please check it out.
> > >
> > > Features pop into the code-base without any discussion, they also get
> > > removed without any discussion. PRs come in when the feature is
> complete,
> > > not giving others  opportunity to understand/contribute or have a say.
> > >
> > > If this project embraces the true Apache spirit and follow successful
> > > practices we could get lot more people excited about this project. Many
> > > successful Apache projects use JIRA, look at Apache Spark which has
> 1250+
> > > contributors and built a community of 500,000 people around the world.
> > >
> > > -Naveen
> > >
> > >
> > > On Fri, Jun 8, 2018 at 10:27 AM, Eric Xie  wrote:
> > >
> > > > Hi,
> > > >
> > > > Since all of MXNet's development happens on Github, I think it's
> > > > sufficient to use Github Issues and Github Projects for tracking.
> There
> > > are
> > > > also many other plugins you can add to Github if issues and projects
> are
> > > > not enough.
> > > >
> > > > It's very easy to cross reference PRs and issues for tracking. In
> > > > comparison, JIRA is an outdated system with very little features and
> no
> > > > integration with Github. I think using it achieves nothing but
> additional
> > > > overhead.
> > > >
> > > > Thanks,
> > > > Eric
> > > >
> > >
> >
>

Re: Regarding 1.2.1 patch release

[Anirudh]

Hi all,

I have added the following PRs to the list :
MKLDNN:
https://github.com/apache/incubator-mxnet/pull/10706

RPI:
https://github.com/apache/incubator-mxnet/pull/11054

Docs/CI:
https://github.com/apache/incubator-mxnet/pull/10485
https://github.com/apache/incubator-mxnet/pull/10728
https://github.com/apache/incubator-mxnet/pull/10785
https://github.com/apache/incubator-mxnet/pull/11066

Anirudh


On Fri, Jun 8, 2018 at 9:16 AM, Marco de Abreu  wrote:

> Thanks a lot Aaron for addressing this in such a timely manner!
>
> It would definitely be great to see the raspberry build fixes in that
> branch since it's currently broken.
>
> -Marco
>
> Aaron Markham  schrieb am Fr., 8. Juni 2018,
> 18:10:
>
> > Hi Anirudh,
> > Marco brought my attention to CI failures on the 1.2.1 builds with regard
> > to docs. The failures are because the build scripts that are in the 1.2.0
> > branch are out of date and have problems due to package updates that are
> > incompatible with each other.
> >
> > To fix this you'll need to bring all of the docs building scripts
> > up-to-date. There were a few updates prior to #10485, so if those are
> > missing from 1.2.0, they might need to be included too. (#10270,#10010,
> > #9878)
> >
> > Please use this major update to docs building:
> > https://github.com/apache/incubator-mxnet/pull/10485
> >
> > These update docs to reflect the changes:
> > https://github.com/apache/incubator-mxnet/pull/10728
> > https://github.com/apache/incubator-mxnet/pull/10785
> >
> > This updates the Jenkinsfile to secure nodes:
> > https://github.com/apache/incubator-mxnet/pull/11066
> >
> > Please let me know if you have any questions.
> >
> > Cheers,
> > Aaron
> >
> > On Fri, Jun 8, 2018 at 6:34 AM, Anton Chernov 
> wrote:
> >
> > > I would like to propose [1] as an important fix for RaspberryPi's for
> the
> > > 1.2 patch release.
> > >
> > > -- Anton
> > >
> > > [1] https://github.com/apache/incubator-mxnet/pull/11054
> > >
> > > 2018-06-08 1:44 GMT+02:00 Zheng, Da :
> > >
> > > > Hello Anirudh,
> > > >
> > > > There is a test (test_hybrid_multi_context) for
> > > https://github.com/apache/
> > > > incubator-mxnet/pull/10706
> > > > It's also tested by the C++ unit tests in https://github.com/apache/
> > > > incubator-mxnet/pull/10979
> > > > https://github.com/apache/incubator-mxnet/pull/10979/files#diff-
> > > > 8118d4fd8d897a9177f48257a466ea13R435
> > > >
> > > > Best,
> > > > Da
> > > >
> > > > On 6/7/18, 3:37 PM, "Anirudh"  wrote:
> > > >
> > > > Hi Da,
> > > >
> > > > Can you please open a PR to the 1.2 branch with the following PRs
> > > > mentioned
> > > > by you and Tao cherry picked onto release branch.
> > > >
> > > > https://github.com/apache/incubator-mxnet/pull/10979
> > > > https://github.com/apache/incubator-mxnet/pull/10731
> > > > https://github.com/apache/incubator-mxnet/pull/10651
> > > > https://github.com/apache/incubator-mxnet/pull/10624
> > > > https://github.com/apache/incubator-mxnet/pull/10619
> > > > https://github.com/apache/incubator-mxnet/pull/10616
> > > > https://github.com/apache/incubator-mxnet/pull/10918
> > > > https://github.com/apache/incubator-mxnet/pull/10613
> > > >
> > > > I am a little concerned about the below two PRs since they don't
> > have
> > > > enough tests:
> > > > https://github.com/apache/incubator-mxnet/pull/10706
> > > > https://github.com/apache/incubator-mxnet/pull/10810
> > > >
> > > > 
> > > > Can you please talk about the test coverage of these two PRs.
> > > >
> > > > Hi Tao,
> > > >
> > > > To answer your question about the criteria for choosing PRs for
> > patch
> > > > release: I think we haven't done patch release many times before
> > and
> > > we
> > > > don't have a clear set of criteria on what can go into the patch
> > > > release.
> > > > The main intention of doing patch release is to fix the
> > undocumented
> > > > backwards incompatible change from 1.1. Along with this critical
> > > fixes
> > > > should also be pushed out. AFAIK, The "critical" here is not
> > clearly
> > > > defined by the community yet and we should use our best judgement
> > > here.
> > > > According to me,  everything which has potential to impact a
> large
> > > > number
> > > > of MXNet users can be considered critical.
> > > >
> > > > The timeline for the patch release is "as soon as possible".
> > > > https://github.com/apache/incubator-mxnet/pull/11049 is not
> > critical
> > > > and
> > > > will show up in mxnet.io docs in master when it is merged. I
> would
> > > be
> > > > little hesitant about https://github.com/apache/
> > > > incubator-mxnet/pull/11095
> > > > since it lacks test currently. We can consider
> > > > https://github.com/apache/incubator-mxnet/pull/11047 if it is
> > merged
> > > > in
> > > > time.
> > > >
> > > > Anirudh
> > > >
> > 

Re: Vote to stop using JIRA

[Marco de Abreu]

+1

While the intention of JIRA was good, we have proven as a community that we
are not able to use it properly and it's only being a burden. The initial
idea was that it allows us to manage projects publicly, make plans and
allow everybody to engage into these projects by just picking small tasks.

The reality is that everybody is just copy and pasting the PR title into
JIRA, there are no projects with subtasks, tickets are not maintained and
just stay open, there is no labelling in place or anything. In that state,
it does not provide any value. I don't really see how this is going to
change and thus it's better to remove the system altogether.

It's a pity that we as a community were not able to get this to work, but
that's the reality. In the best interest of our contributors, it'd be the
best to remove it again.

Best regards,
Marco

Mu Li  schrieb am Fr., 8. Juni 2018, 19:49:

> Hi Naveen,
>
> Can we clarify that how JIRA improved the project?  One key Apache spirit
> is
> about transparent, but I didn't see the current way we are using JIRA
> improves it. Comparing to Spark, one major problem is that we have 10x less
> active contributors. Even PyTorch is 3x more active (#commits, #LOC
> #contributors) than us. If JIRA makes contributing harder, we should
> consider a better approach.
>
> Best
> Mu
>
> On Fri, Jun 8, 2018 at 10:35 AM, Naveen Swamy  wrote:
>
> > -1 (binding)
> >
> > The very reason why JIRA was suggested so that the project is more open
> on
> > the features that are worked on. There are 900+ issues, that once in a
> > while gets closed without any reason has happened already once.
> > There is already integration with GitHub PRs, please check it out.
> >
> > Features pop into the code-base without any discussion, they also get
> > removed without any discussion. PRs come in when the feature is complete,
> > not giving others  opportunity to understand/contribute or have a say.
> >
> > If this project embraces the true Apache spirit and follow successful
> > practices we could get lot more people excited about this project. Many
> > successful Apache projects use JIRA, look at Apache Spark which has 1250+
> > contributors and built a community of 500,000 people around the world.
> >
> > -Naveen
> >
> >
> > On Fri, Jun 8, 2018 at 10:27 AM, Eric Xie  wrote:
> >
> > > Hi,
> > >
> > > Since all of MXNet's development happens on Github, I think it's
> > > sufficient to use Github Issues and Github Projects for tracking. There
> > are
> > > also many other plugins you can add to Github if issues and projects
> are
> > > not enough.
> > >
> > > It's very easy to cross reference PRs and issues for tracking. In
> > > comparison, JIRA is an outdated system with very little features and no
> > > integration with Github. I think using it achieves nothing but
> additional
> > > overhead.
> > >
> > > Thanks,
> > > Eric
> > >
> >
>

Re: Vote to stop using JIRA

[Tianqi Chen]

I would suggest we have a separate discussion issue about transparency.
First of all, I agree that transparency is important.

This can be achieved by public roadmaps, RFCs, that do not have
particularly tie to JIRA or github issues. Having a clear guideline on that
would be great, and it is great to see more RFCs in the dev list.

In terms of issues themselves, I think one problem we are facing is
overflowing amount of issues. One way to minimize this would be to redirect
more questions to forums, and only keep issues that are actionable and
encourage the committers who opens the issue to fix them timely.

Tianqi

On Fri, Jun 8, 2018 at 10:35 AM, Naveen Swamy  wrote:

> -1 (binding)
>
> The very reason why JIRA was suggested so that the project is more open on
> the features that are worked on. There are 900+ issues, that once in a
> while gets closed without any reason has happened already once.
> There is already integration with GitHub PRs, please check it out.
>
> Features pop into the code-base without any discussion, they also get
> removed without any discussion. PRs come in when the feature is complete,
> not giving others  opportunity to understand/contribute or have a say.
>
> If this project embraces the true Apache spirit and follow successful
> practices we could get lot more people excited about this project. Many
> successful Apache projects use JIRA, look at Apache Spark which has 1250+
> contributors and built a community of 500,000 people around the world.
>
> -Naveen
>
>
> On Fri, Jun 8, 2018 at 10:27 AM, Eric Xie  wrote:
>
> > Hi,
> >
> > Since all of MXNet's development happens on Github, I think it's
> > sufficient to use Github Issues and Github Projects for tracking. There
> are
> > also many other plugins you can add to Github if issues and projects are
> > not enough.
> >
> > It's very easy to cross reference PRs and issues for tracking. In
> > comparison, JIRA is an outdated system with very little features and no
> > integration with Github. I think using it achieves nothing but additional
> > overhead.
> >
> > Thanks,
> > Eric
> >
>

Re: Vote to stop using JIRA

[Mu Li]

Hi Naveen,

Can we clarify that how JIRA improved the project?  One key Apache spirit is
about transparent, but I didn't see the current way we are using JIRA
improves it. Comparing to Spark, one major problem is that we have 10x less
active contributors. Even PyTorch is 3x more active (#commits, #LOC
#contributors) than us. If JIRA makes contributing harder, we should
consider a better approach.

Best
Mu

On Fri, Jun 8, 2018 at 10:35 AM, Naveen Swamy  wrote:

> -1 (binding)
>
> The very reason why JIRA was suggested so that the project is more open on
> the features that are worked on. There are 900+ issues, that once in a
> while gets closed without any reason has happened already once.
> There is already integration with GitHub PRs, please check it out.
>
> Features pop into the code-base without any discussion, they also get
> removed without any discussion. PRs come in when the feature is complete,
> not giving others  opportunity to understand/contribute or have a say.
>
> If this project embraces the true Apache spirit and follow successful
> practices we could get lot more people excited about this project. Many
> successful Apache projects use JIRA, look at Apache Spark which has 1250+
> contributors and built a community of 500,000 people around the world.
>
> -Naveen
>
>
> On Fri, Jun 8, 2018 at 10:27 AM, Eric Xie  wrote:
>
> > Hi,
> >
> > Since all of MXNet's development happens on Github, I think it's
> > sufficient to use Github Issues and Github Projects for tracking. There
> are
> > also many other plugins you can add to Github if issues and projects are
> > not enough.
> >
> > It's very easy to cross reference PRs and issues for tracking. In
> > comparison, JIRA is an outdated system with very little features and no
> > integration with Github. I think using it achieves nothing but additional
> > overhead.
> >
> > Thanks,
> > Eric
> >
>

Re: Vote to stop using JIRA

[Naveen Swamy]

-1 (binding)

The very reason why JIRA was suggested so that the project is more open on
the features that are worked on. There are 900+ issues, that once in a
while gets closed without any reason has happened already once.
There is already integration with GitHub PRs, please check it out.

Features pop into the code-base without any discussion, they also get
removed without any discussion. PRs come in when the feature is complete,
not giving others  opportunity to understand/contribute or have a say.

If this project embraces the true Apache spirit and follow successful
practices we could get lot more people excited about this project. Many
successful Apache projects use JIRA, look at Apache Spark which has 1250+
contributors and built a community of 500,000 people around the world.

-Naveen


On Fri, Jun 8, 2018 at 10:27 AM, Eric Xie  wrote:

> Hi,
>
> Since all of MXNet's development happens on Github, I think it's
> sufficient to use Github Issues and Github Projects for tracking. There are
> also many other plugins you can add to Github if issues and projects are
> not enough.
>
> It's very easy to cross reference PRs and issues for tracking. In
> comparison, JIRA is an outdated system with very little features and no
> integration with Github. I think using it achieves nothing but additional
> overhead.
>
> Thanks,
> Eric
>

Vote to stop using JIRA

[Eric Xie]

Hi,

Since all of MXNet's development happens on Github, I think it's sufficient to 
use Github Issues and Github Projects for tracking. There are also many other 
plugins you can add to Github if issues and projects are not enough.

It's very easy to cross reference PRs and issues for tracking. In comparison, 
JIRA is an outdated system with very little features and no integration with 
Github. I think using it achieves nothing but additional overhead.

Thanks,
Eric

Re: Regarding 1.2.1 patch release

[Marco de Abreu]

Thanks a lot Aaron for addressing this in such a timely manner!

It would definitely be great to see the raspberry build fixes in that
branch since it's currently broken.

-Marco

Aaron Markham  schrieb am Fr., 8. Juni 2018,
18:10:

> Hi Anirudh,
> Marco brought my attention to CI failures on the 1.2.1 builds with regard
> to docs. The failures are because the build scripts that are in the 1.2.0
> branch are out of date and have problems due to package updates that are
> incompatible with each other.
>
> To fix this you'll need to bring all of the docs building scripts
> up-to-date. There were a few updates prior to #10485, so if those are
> missing from 1.2.0, they might need to be included too. (#10270,#10010,
> #9878)
>
> Please use this major update to docs building:
> https://github.com/apache/incubator-mxnet/pull/10485
>
> These update docs to reflect the changes:
> https://github.com/apache/incubator-mxnet/pull/10728
> https://github.com/apache/incubator-mxnet/pull/10785
>
> This updates the Jenkinsfile to secure nodes:
> https://github.com/apache/incubator-mxnet/pull/11066
>
> Please let me know if you have any questions.
>
> Cheers,
> Aaron
>
> On Fri, Jun 8, 2018 at 6:34 AM, Anton Chernov  wrote:
>
> > I would like to propose [1] as an important fix for RaspberryPi's for the
> > 1.2 patch release.
> >
> > -- Anton
> >
> > [1] https://github.com/apache/incubator-mxnet/pull/11054
> >
> > 2018-06-08 1:44 GMT+02:00 Zheng, Da :
> >
> > > Hello Anirudh,
> > >
> > > There is a test (test_hybrid_multi_context) for
> > https://github.com/apache/
> > > incubator-mxnet/pull/10706
> > > It's also tested by the C++ unit tests in https://github.com/apache/
> > > incubator-mxnet/pull/10979
> > > https://github.com/apache/incubator-mxnet/pull/10979/files#diff-
> > > 8118d4fd8d897a9177f48257a466ea13R435
> > >
> > > Best,
> > > Da
> > >
> > > On 6/7/18, 3:37 PM, "Anirudh"  wrote:
> > >
> > > Hi Da,
> > >
> > > Can you please open a PR to the 1.2 branch with the following PRs
> > > mentioned
> > > by you and Tao cherry picked onto release branch.
> > >
> > > https://github.com/apache/incubator-mxnet/pull/10979
> > > https://github.com/apache/incubator-mxnet/pull/10731
> > > https://github.com/apache/incubator-mxnet/pull/10651
> > > https://github.com/apache/incubator-mxnet/pull/10624
> > > https://github.com/apache/incubator-mxnet/pull/10619
> > > https://github.com/apache/incubator-mxnet/pull/10616
> > > https://github.com/apache/incubator-mxnet/pull/10918
> > > https://github.com/apache/incubator-mxnet/pull/10613
> > >
> > > I am a little concerned about the below two PRs since they don't
> have
> > > enough tests:
> > > https://github.com/apache/incubator-mxnet/pull/10706
> > > https://github.com/apache/incubator-mxnet/pull/10810
> > >
> > > 
> > > Can you please talk about the test coverage of these two PRs.
> > >
> > > Hi Tao,
> > >
> > > To answer your question about the criteria for choosing PRs for
> patch
> > > release: I think we haven't done patch release many times before
> and
> > we
> > > don't have a clear set of criteria on what can go into the patch
> > > release.
> > > The main intention of doing patch release is to fix the
> undocumented
> > > backwards incompatible change from 1.1. Along with this critical
> > fixes
> > > should also be pushed out. AFAIK, The "critical" here is not
> clearly
> > > defined by the community yet and we should use our best judgement
> > here.
> > > According to me,  everything which has potential to impact a large
> > > number
> > > of MXNet users can be considered critical.
> > >
> > > The timeline for the patch release is "as soon as possible".
> > > https://github.com/apache/incubator-mxnet/pull/11049 is not
> critical
> > > and
> > > will show up in mxnet.io docs in master when it is merged. I would
> > be
> > > little hesitant about https://github.com/apache/
> > > incubator-mxnet/pull/11095
> > > since it lacks test currently. We can consider
> > > https://github.com/apache/incubator-mxnet/pull/11047 if it is
> merged
> > > in
> > > time.
> > >
> > > Anirudh
> > >
> > >
> > >
> > > On Thu, Jun 7, 2018 at 2:27 PM, Naveen Swamy 
> > > wrote:
> > >
> > > > Hi Anirudh,
> > > >
> > > > I would like to get the fixes that was made to publish to Maven
> > into
> > > 1.2.1
> > > > -- currently in PR https://github.com/apache/
> > > incubator-mxnet/pull/11147/
> > > >
> > > > Also additionally, I would like to get the fix for
> > > > https://github.com/apache/incubator-mxnet/issues/10436 -
> currently
> > > another
> > > > contributor Andrew is working on it.
> > > >
> > > > -Naveen
> > > >
> > > > On Thu, Jun 7, 2018 at 8:33 AM, Lv, Tao A 
> > > wrote:
> > > >
> > > > > Thanks for bringing this up, Da!
> > > > >
> 

Re: Regarding 1.2.1 patch release

[Aaron Markham]

Hi Anirudh,
Marco brought my attention to CI failures on the 1.2.1 builds with regard
to docs. The failures are because the build scripts that are in the 1.2.0
branch are out of date and have problems due to package updates that are
incompatible with each other.

To fix this you'll need to bring all of the docs building scripts
up-to-date. There were a few updates prior to #10485, so if those are
missing from 1.2.0, they might need to be included too. (#10270,#10010,
#9878)

Please use this major update to docs building:
https://github.com/apache/incubator-mxnet/pull/10485

These update docs to reflect the changes:
https://github.com/apache/incubator-mxnet/pull/10728
https://github.com/apache/incubator-mxnet/pull/10785

This updates the Jenkinsfile to secure nodes:
https://github.com/apache/incubator-mxnet/pull/11066

Please let me know if you have any questions.

Cheers,
Aaron

On Fri, Jun 8, 2018 at 6:34 AM, Anton Chernov  wrote:

> I would like to propose [1] as an important fix for RaspberryPi's for the
> 1.2 patch release.
>
> -- Anton
>
> [1] https://github.com/apache/incubator-mxnet/pull/11054
>
> 2018-06-08 1:44 GMT+02:00 Zheng, Da :
>
> > Hello Anirudh,
> >
> > There is a test (test_hybrid_multi_context) for
> https://github.com/apache/
> > incubator-mxnet/pull/10706
> > It's also tested by the C++ unit tests in https://github.com/apache/
> > incubator-mxnet/pull/10979
> > https://github.com/apache/incubator-mxnet/pull/10979/files#diff-
> > 8118d4fd8d897a9177f48257a466ea13R435
> >
> > Best,
> > Da
> >
> > On 6/7/18, 3:37 PM, "Anirudh"  wrote:
> >
> > Hi Da,
> >
> > Can you please open a PR to the 1.2 branch with the following PRs
> > mentioned
> > by you and Tao cherry picked onto release branch.
> >
> > https://github.com/apache/incubator-mxnet/pull/10979
> > https://github.com/apache/incubator-mxnet/pull/10731
> > https://github.com/apache/incubator-mxnet/pull/10651
> > https://github.com/apache/incubator-mxnet/pull/10624
> > https://github.com/apache/incubator-mxnet/pull/10619
> > https://github.com/apache/incubator-mxnet/pull/10616
> > https://github.com/apache/incubator-mxnet/pull/10918
> > https://github.com/apache/incubator-mxnet/pull/10613
> >
> > I am a little concerned about the below two PRs since they don't have
> > enough tests:
> > https://github.com/apache/incubator-mxnet/pull/10706
> > https://github.com/apache/incubator-mxnet/pull/10810
> >
> > 
> > Can you please talk about the test coverage of these two PRs.
> >
> > Hi Tao,
> >
> > To answer your question about the criteria for choosing PRs for patch
> > release: I think we haven't done patch release many times before and
> we
> > don't have a clear set of criteria on what can go into the patch
> > release.
> > The main intention of doing patch release is to fix the undocumented
> > backwards incompatible change from 1.1. Along with this critical
> fixes
> > should also be pushed out. AFAIK, The "critical" here is not clearly
> > defined by the community yet and we should use our best judgement
> here.
> > According to me,  everything which has potential to impact a large
> > number
> > of MXNet users can be considered critical.
> >
> > The timeline for the patch release is "as soon as possible".
> > https://github.com/apache/incubator-mxnet/pull/11049 is not critical
> > and
> > will show up in mxnet.io docs in master when it is merged. I would
> be
> > little hesitant about https://github.com/apache/
> > incubator-mxnet/pull/11095
> > since it lacks test currently. We can consider
> > https://github.com/apache/incubator-mxnet/pull/11047 if it is merged
> > in
> > time.
> >
> > Anirudh
> >
> >
> >
> > On Thu, Jun 7, 2018 at 2:27 PM, Naveen Swamy 
> > wrote:
> >
> > > Hi Anirudh,
> > >
> > > I would like to get the fixes that was made to publish to Maven
> into
> > 1.2.1
> > > -- currently in PR https://github.com/apache/
> > incubator-mxnet/pull/11147/
> > >
> > > Also additionally, I would like to get the fix for
> > > https://github.com/apache/incubator-mxnet/issues/10436 - currently
> > another
> > > contributor Andrew is working on it.
> > >
> > > -Naveen
> > >
> > > On Thu, Jun 7, 2018 at 8:33 AM, Lv, Tao A 
> > wrote:
> > >
> > > > Thanks for bringing this up, Da!
> > > >
> > > > It would be great if we can have these fixes into 1.2.1 patch
> > release,
> > > > especially for https://github.com/apache/
> > incubator-mxnet/pull/10651, it
> > > > has fixed https://github.com/apache/incubator-mxnet/issues/11028
> .
> > > >
> > > > What I want to add are:
> > > > 1. https://github.com/apache/incubator-mxnet/pull/10810 which
> > fixed
> > > > https://github.com/apache/incubator-mxnet/issues/10809 .
> > > > 2. 

Re: Request for Sign up

[Ivan Serdyuk]

Hi. I am still not able to join Slack cahnnel.

On Thu, Jun 7, 2018 at 10:56 PM, Steffen Rochel 
wrote:

> Hi Kalyanee - welcome! Added you to slack channel.
> Steffen
>
> On Thu, Jun 7, 2018 at 11:44 AM Kalyanee Chendke 
> wrote:
>
> > Hey!
> >
> > I would like to request for sign up to the MXNet Apache Mailing list &
> also
> > to the MXNet Slack Channel.
> >
> > Kalyanee
> >
>