Re: Help to subscribe MXNet Slack channel

[大嶋悠司]

Hi Jun

Thank you for the reply and to share your work! That's great!
I agree with using tensorboard for visualization and I made small PR for
Histogram callback( https://github.com/apache/incubator-mxnet/pull/9994 )
Though I worried about that the dmlc/tensorboard repo would be maintained,
by looking your branch I clearly understood that you will make not to
depend on that repo.
I agree with your design and willing to contribute it in any way.
I want to add the visualization of graphs support.
According to your document, it's TBD and depends on ONNX-mxnet.
Does the reason of depending on ONNX is that you would like to use
"torch.onnx._optimize_trace" method?

Thanks,
Yuji

2018-03-06 15:36 GMT+09:00 Jun Wu :

> Hi Yuji,
>
> Welcome to the MXNet community!
>
> We have been working on delivering a complete logging solution in MXNet
> for users to employ the TensorFlow's TensorBoard for visualization. You can
> find our work in the following links:
> - Design Doc: https://cwiki.apache.org/confluence/display/MXNET/
> Logging+MXNet+Data+for+Visualization+in+TensorBoard
> 
> - GitHub Working Branch: https://github.com/reminisce/mxnet/tree/
> tensorboard_logging
>
> It's mostly functional, and we are adding unit tests, tutorials, and
> documentation for APIs to make the code mergeable to the MXNet master
> branch.
>
> In order not to duplicate efforts on both sides, could you share your work
> plan so that we can decide on how to move forward?
>
> Thanks,
> Jun
>
> On Mon, Mar 5, 2018 at 10:02 PM, 大嶋悠司  wrote:
>
>> Hi,
>>
>> I am Yuji from NTT Research team to work on improving logging and
>> visualization of MXNet.
>> Would you help to add me into the Slack channel? Thanks.
>>
>> Best Regards,
>> Yuji Oshima
>>
>
>

Re: Help to subscribe MXNet Slack channel

[Jun Wu]

Hi Yuji,

Welcome to the MXNet community!

We have been working on delivering a complete logging solution in MXNet for
users to employ the TensorFlow's TensorBoard for visualization. You can
find our work in the following links:
- Design Doc:
 
https://cwiki.apache.org/confluence/display/MXNET/Logging+MXNet+Data+for+Visualization+in+TensorBoard

- GitHub Working Branch:
https://github.com/reminisce/mxnet/tree/tensorboard_logging

It's mostly functional, and we are adding unit tests, tutorials, and
documentation for APIs to make the code mergeable to the MXNet master
branch.

In order not to duplicate efforts on both sides, could you share your work
plan so that we can decide on how to move forward?

Thanks,
Jun

On Mon, Mar 5, 2018 at 10:02 PM, 大嶋悠司  wrote:

> Hi,
>
> I am Yuji from NTT Research team to work on improving logging and
> visualization of MXNet.
> Would you help to add me into the Slack channel? Thanks.
>
> Best Regards,
> Yuji Oshima
>

Help to subscribe MXNet Slack channel

[大嶋悠司]

Hi,

I am Yuji from NTT Research team to work on improving logging and
visualization of MXNet.
Would you help to add me into the Slack channel? Thanks.

Best Regards,
Yuji Oshima

Re: Following semantic versioning

[Naveen Swamy]

I think its important to understand someone's day_job's customer is also a
user of MXNet. Right now MXNet project needs to put effort in helping users
and bringing them on-board. I don't think its a good idea to ask the
customer to come back after a new release is made or ask to use a fork.

With regards to CI test not running on a older branch, I don't think its Ok
to ditch a released branch just because a release was made. why are tests
not triggered when a PR is made on an older branch(regardless of new
feature or a bug fix) ?.

May be we should think about making minor releases on released branches.





On Mon, Mar 5, 2018 at 3:25 PM, Marco de Abreu  wrote:

> Hello,
>
> we recently had a few cases in which it has been attempted to add new
> functionality to old branches because a customer of somebodys $DAY_JOB
> requested it and was unable to switch to the latest release or that certain
> feature did not make it into the release. This lead to quite a lot of
> discussions and there was no clear standing within the community.
>
> Just to cite semantic versioning:
>
>1. MAJOR version when you make incompatible API changes,
>2. MINOR version when you add functionality in a backwards-compatible
>manner, and
>3. PATCH version when you make backwards-compatible bug fixes.
>
>
> We as a community agreed on following this system and I think we should
> either stick to it or drop it entirely - exceptions to SemVer are usually
> discouraged. While I see that adding functionality might be a minor thing,
> I don't think that we should educate our users into expecting us to
> backport new features. The development happening on the Apache MXNet
> repository should not be influenced by something like this; especially
> considering that whoever supports that customer on their $DAY_JOB can
> assist them at creating a fork and cherrypicking that feature. But I don't
> see much reason why we're running against best pracitices. One important
> thing to note here is that we're not maintaining CI on old branches and
> neither are we making patch releases - so what do these users do? Compile
> off a stale development branch with unvalidated changes?
>
> In my opinion this whole topic is just causing trouble and fragementation
> on our end. If a features doesn't make it into the release (for whatever
> reason), so be it. But I think we should discuss this topic and emphasize a
> no-exceptions-rule to SemVer.
>
> Best regards,
> Marco
>

404 issues

[Aaron Markham]

I've been notified by several parties about 404s for files that are
now longer available on the site.
https://github.com/apache/incubator-mxnet/issues/9917

This page returns 404:
https://mxnet.incubator.apache.org/api/python/module.html

It was moved here:
https://mxnet.incubator.apache.org/api/python/module/module.html

There are many other examples of moved content. Some are temporarily
"fixed" via adding a meta-refresh tag in the html source for the old
pages. For example the meta tag is being used to redirect to faq, the
new location for the how_to docs.

It would seem a better solution for us is to use htaccess files and
publish persistent redirects for the new location(s) of content.

Do we have a way of pushing a config to the Apache infra to facilitate
this? I think we'd need config access if we're to put up some custom
404 pages too (which would be nicer than what we have now.)

Also, is there a good way to access the log files to get a better idea
of the 404 situation?

Cheers,
Aaron

Following semantic versioning

[Marco de Abreu]

Hello,

we recently had a few cases in which it has been attempted to add new
functionality to old branches because a customer of somebodys $DAY_JOB
requested it and was unable to switch to the latest release or that certain
feature did not make it into the release. This lead to quite a lot of
discussions and there was no clear standing within the community.

Just to cite semantic versioning:

   1. MAJOR version when you make incompatible API changes,
   2. MINOR version when you add functionality in a backwards-compatible
   manner, and
   3. PATCH version when you make backwards-compatible bug fixes.


We as a community agreed on following this system and I think we should
either stick to it or drop it entirely - exceptions to SemVer are usually
discouraged. While I see that adding functionality might be a minor thing,
I don't think that we should educate our users into expecting us to
backport new features. The development happening on the Apache MXNet
repository should not be influenced by something like this; especially
considering that whoever supports that customer on their $DAY_JOB can
assist them at creating a fork and cherrypicking that feature. But I don't
see much reason why we're running against best pracitices. One important
thing to note here is that we're not maintaining CI on old branches and
neither are we making patch releases - so what do these users do? Compile
off a stale development branch with unvalidated changes?

In my opinion this whole topic is just causing trouble and fragementation
on our end. If a features doesn't make it into the release (for whatever
reason), so be it. But I think we should discuss this topic and emphasize a
no-exceptions-rule to SemVer.

Best regards,
Marco

Help to subscribe MXNet Slack channel

[Huang, Jin1]

Hi,

I am Jin from Intel Shanghai team to work on MXNet integration with Intel 
library, would you help to add me into the Slack channel? Thanks.

Best Regards,
Jin Huang