Blair Zajac <[EMAIL PROTECTED]> wrote: >> What are the other issues? I don't like patches to shut up warnings >> caused by bugs/imperfections in external tools. If the tools help >> finding out real bugs, that's fine, let's fix them. But I'm -1 on >> any patch that tries to adjust code so to shut down non-issues >> and/or change our code to follow some coding convention (like the >> "is None" issue) the tools unilaterally decided it's the Good >> One(TM). > > The Subversion teams takes care to remove all gcc -Wall warnings from > the C source code and I don't see why that shouldn't extend to > svnmerge.py.
-Wall contains a carefully set of warnings, tuned by many developers across the last 10 years. GCC developers recommend using -Wall -Werror, they know many people do follow this advice, and try as hard as possible to not break it with new bogus warnings, avoid false positives, avoid warnings that aren't a clear indicator of a serious issue in the code, etc. For instance, there are violent discussions whether a new warning should go to -Wall or -Wextra. OTOH, pychecker is a recent effort, done by one person, without reaching any consensus with the Python community. It spews many false positives, contains even coding style suggestions, etc. Comparing it with -Wall is not correct. It's more like having "-Wall -Wextra -Weffc++". Moreoever, there are other competing tools around (see PyLint), which produce other sets of warnings, other false positives, etc. Are we going to try and get a clear run with PyLint too? Giovanni Bajo _______________________________________________ Svnmerge mailing list [email protected] http://www.orcaware.com/mailman/listinfo/svnmerge
