It would be great to enforce the check for warnings and treat as errors. Some questions I have: - what are the warnings that you think should be ignored? - for the rest of the warning types, can we turn them on one by one?
-sz On 2019/05/21 22:33:51, Pedro Larroy <pedro.larroy.li...@gmail.com> wrote: > Hi dev@ > > I try to fix any warning that I see during compilation of MXNet in my > platform and with the build toggles that I care about. These seemingly > trivial and ungrateful efforts, take nonetheless energy on the > contributor side. > > I think overall I submitted myself more than a dozen of PRs fixing > warnings and I would like to call for additional help and > contributions in this area. > > There was a question from Lin about discussing this on the mailing > list, I have the feeling that everybody agrees on moving towards zero > warnings and warnings as errors. I think there are unavoidable > warnings that can be disabled specifically such as the one triggered > by mshadow type switch. > > Some important missing warnings such as warning on missing return > values (ie. forgetting to return on a function returning non-void) > cause bugs, danger and additional time spent bugfixing, which can be > better spent somewhere else. > > Is there a process that we can figure out such as a more expedited > merges of PRs fixing warnings or a specific label? > > Some simple PRs that fixes a warning can take long to merge, and > sometimes trigger too much discussion and make the progress a bit > unfriendly to contributors. > > Any help or constructive ideas on this topic would be appreciated. > > Pedro. >