It seems we have the `DEV` mode
(https://github.com/apache/incubator-mxnet/blob/master/make/config.mk#L28) to
do that? Is it correct?
Xingjian
From: Ziyue Huang
Sent: Tuesday, January 16, 2018 9:01 AM
To: dev@mxnet.incubator.apache.org
+1
On Mon, Jan 15, 2018 at 8:02 PM Ziyue Huang wrote:
> +1 since warnings might be potential errors. In my perspective, an
> excellent project is better to have 0 warnings.
>
> Chris Olivier 于2018年1月16日 周二上午2:27写道:
>
> > If enabled, it should only
+1
On Mon, Jan 15, 2018 at 4:40 PM, Steffen Rochel
wrote:
> Thanks for all the feedback!
> Proposed a simplified version in
> https://github.com/apache/incubator-mxnet/pull/9448 :
>
> # Owners of Apache MXNet
> # Please see documentation of use of CODEOWNERS file at
> #
Thanks for all the feedback!
Proposed a simplified version in
https://github.com/apache/incubator-mxnet/pull/9448 :
# Owners of Apache MXNet
# Please see documentation of use of CODEOWNERS file at
# https://help.github.com/articles/about-codeowners/ and
#
Very good points, Chris! +1
If the community does not want to support a specific part of MXNet but
there's a business interest, the company can assign somebody for this task
and if this person is doing good work, they might be added as a committer
in the long-term, closing the loop. If there's no
I'm not sure I understand the "orphaned package" thing. You mean that no
one is reviewing them?
If a corporation wishes to assign a particular portion of the code to an
employee to review regularly, then that can take care of any portions
becoming "orphaned", but it can't mean "this person we
Hello Community,
I am working on adding Apache MXNet backend for Keras2. Jiajie Chen, MXNet
contributor, was actively involved and has contributed many operators and
functionalities. Thanks to early contributors for Keras1.2 which we have
extended in this work.
I hereby request for Apache
If enabled, it should only cause errors in Release builds, since having
warnings in WIP code is not unusual.
In addition, different developers use different gcc/clang versions. Some
gcc versions, for instance, generate warnings where others do not. It
would not be fair to render unbuildable a
+1 (binding)
On Mon, Jan 15, 2018 at 9:43 AM, Marco de Abreu <
marco.g.ab...@googlemail.com> wrote:
> +1
>
> On Mon, Jan 15, 2018 at 6:27 PM, Pedro Larroy <
> pedro.larroy.li...@gmail.com>
> wrote:
>
> > Hi
> >
> > I would like to propose to compile in CI with warnings as errors for
> >
Hi
I would like to propose to compile in CI with warnings as errors for
increased code quality. This has a dual purpose:
1. Enforce a clean compilation output. Warnings often indicate
deficiencies in the code and hide new warnings which can be an
indicator of problems.
2. Warnings can surface
Add them to contributor guide if needed, that is what contributor guide is
for.
We only need a few pages of things instead of a book which people won't
comprehend, in a short period. The current guidelines include the style
Guide and I suggest we add follow RAII when possible
Tianqi
On Mon,
There's tons of books on "best practices", some even outdated. But the
question is, do we think it ads value to our project to have a small
distilled list of good software engineering and specific language
practices and idioms that We decide to stick with in our project?
This could be a one or two
+1
Agree with Bhavin, Marco and Sheng. I would also like to point out
good commit practices such as, keeping each individual commit small
and on-topic, meaning if that you are changing whitespace and a one
liner fix, it's better practice to separate those commits. Or having
two separate commits
Agree with Bhavin's arguments 100%. Please don't compromise the
stability of CI with Flaky tests. Address the root cause of why these
tests are failing / not deterministic as per propper engineering
standards.
Hence, my non-binding vote is:
-1 for proposal #1 for re-enabling flaky tests.
+1 for
14 matches
Mail list logo