> On Jan 25, 2015, at 7:21 AM, exar...@twistedmatrix.com wrote: > 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.
I think the consensus rule we are converging on for this is, if you notice a bug in the tool, you have to report the bug in the tool. If the bug already exists, just link to the issue which is affected by that bug, but if it's actually a bug and not just a coding-standard thing you don't feel like fixing, you should not block development on it. This seems like the right way to proceed with spurious warnings so we don't add tons of pointless busy-work but we also don't just develop a culture of only a special inner circle knowing which warnings are OK to ignore. >> Does this mean that The (boy) scout rule does not apply for Twisted >> development? > > I'm not familiar with "The (boy) scout rule". I believe that Adi is referring to <http://programmer.97things.oreilly.com/wiki/index.php/The_Boy_Scout_Rule <http://programmer.97things.oreilly.com/wiki/index.php/The_Boy_Scout_Rule>>, "Always leave the campground cleaner than you found it." While every change should be an improvement, I think the Burning Man creed of "no matter out of place" would be a better way to formulate the policy :). You should clean up the things that you're changing, but every unrelated change is an extra burden on the reviewer, so it's not doing anyone any favors to make patches super long to fix every trace of coding standard violation. Having dedicated cleanup branches is fine, but they should also be finite in their scope, and not clean up things beyond the specific area that they're trying to fix. -glyph
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
