<html><body>On 04:01 pm, jacob@internet24.de wrote:<br />>On Fri, 2007-01-12 at 13:14 +0000, glyph@divmod.com wrote:<br />>> Although we should all be happy for the Twisted 2.5 release, we still<br />>> have an unfortunate track-record as far as responsiveness to bugs.<br /><br />>A little bit more flexibility on what patches are added might help.<br /><br />If nobody has said anything about a ticket in 2 years with no patches on it, I don't see how accepting crappy patches is going to help.<br /><br />By "responsiveness" I meant responding to people who report bugs, and being clear on what we are vs. are not working on.  The problem I am trying to address is best described here:<br /><br />    http://www.jwz.org/doc/cadt.html<br /><br />By highlighting the least responsive developer (who, by the way, is Brian Warner) I hope to encourage people to keep their tickets up to date and respond when users report issues, even if the code in question has been rewritten.<br /><br />>If somebody posts a patch to a problem that is not yet<br />>covered by a unit test (so that would be most patches)<br />>then not absolutely insisting that the patcher provides a unit test as<br />>well<br />>could speed up things considerably.<br /><br />All the evidence I've seen (although I admit, there's not much of it) suggests that the opposite is true.  Bugs have been fixed faster and better since the institution of these requirements.<br /><br />Most patches that get submitted without tests address a new ticket that was created specifically to hold the patch.  Very few outside contributors seem to be interested in trying to fix _known_ problems with Twisted.  Either they want a new feature or they want a new problem they've just discovered fixed.<br /><br />Those outside contributors who do contribute to existing tickets have generally become involved with the project enough to know that they should be developing fixes test-first.<br /><br />>If the  developer responsible for<br />>that module thinks the patch is plausible and possibly covers a way to<br />>use twisted which<br />>probably couldn't have worked anyway because of the reported problem,<br />>there<br />>is not all that much risk, is there? After all, the existing tests<br />>should bark if the patch breaks anything else.<br /><br />As Mr. Armstrong already said, this idea doesn't make any sense.  If anything, we need to require tests for existing, old functionality that wasn't completely tested before the patch was applied.<br /><br />>Twisted is really a very cool and effective tool, and that it can<br />>actually be used in a stable production environment is definitely not<br />>something I<br />>want to miss, but maybe that is not so much due to a strict development<br />>policy<br />>as it is due to the skills of the core developers in spotting bogus<br />>changes ;)<br /><br />How do you think the core developers got to be skilled in this way?  By writing patches that don't have any tests or docs in them? :)<br /><br />>Just a thought...<br /><br />Thanks for trying to help with the suggestion.  However, I can guarantee that as long as I am involved with the project, these requirements will continue to stay in place.  You can continue talking about it if you like, but it will not change.<br /><br />>Maybe I got the wrong impression on just how things are done<br />>by the twisted team.<br /><br />You seem to have a roughly correct impression.  Tests and documentation are required before a patch will be accepted.<br /><br />>BTW, the patch in ticket #1794 is already included in 2.5, it probably<br />>shouldn't be an active ticket anymore.<br /><br />Thanks for the heads up - it looks like Thomas Herve closed it in response.<br /></body></html>