On 02:09 pm, a...@roiban.ro wrote:
On 25 January 2015 at 01:01, <exar...@twistedmatrix.com> wrote:
On 24 Jan, 07:51 pm, a...@roiban.ro wrote:
On 24 January 2015 at 19:23, <exar...@twistedmatrix.com> wrote:
On 06:45 pm, a...@roiban.ro wrote:
Hi,
Why reviewing a patch I got into this error from twistedchecker.
This is old code, just that someone it was touched by recent
changes,
Also: pre-existing errors like this one should not block new
development
work being done. It is *not* a requirement that a patch fix all
nearby but
unrelated problems like this one.
OK. but then maybe twistededchecker and pyflakes should not be part of
the stable builders.
In my head, all stable builders should pass before merging new code.
New and changed code should conform to the standard and try not to
introduce
new errors. If the "errors" being introduced are due to bugs in a
tool that
reports errors, the bugs should be fixed.
New code should only try not to introduce new errors?
The tools are there to help development, not hinder it. If a tool is
producing an error that doesn't help development, slavishly adhering to
a policy that requires additional work that doesn't help the project is
counter-productive.
If all the tools were perfect we could say that all new code *must*
never introduce new errors. Unfortunately the tools are not perfect.
I was expecting that new code is not allowed to introduce new errors.
Period.
Existing code *near* new or changed code can and should be left alone.
Does this mean that The (boy) scout rule does not apply for Twisted
development?
I'm not familiar with "The (boy) scout rule".
Jean-Paul
_______________________________________________
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
