[Twisted-Python] Ticket Hall of Shame - Current Loser: Brian Warner

glyph at divmod.com glyph at divmod.com
Fri Jan 12 10:40:07 MST 2007

On 04:01 pm, jacob at internet24.de wrote:
>On Fri, 2007-01-12 at 13:14 +0000, glyph at divmod.com wrote:
>> Although we should all be happy for the Twisted 2.5 release, we still
>> have an unfortunate track-record as far as responsiveness to bugs.

>A little bit more flexibility on what patches are added might help.

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.

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:


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.

>If somebody posts a patch to a problem that is not yet
>covered by a unit test (so that would be most patches)
>then not absolutely insisting that the patcher provides a unit test as
>could speed up things considerably.

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.

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.

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.

>If the  developer responsible for
>that module thinks the patch is plausible and possibly covers a way to
>use twisted which
>probably couldn't have worked anyway because of the reported problem,
>is not all that much risk, is there? After all, the existing tests
>should bark if the patch breaks anything else.

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.

>Twisted is really a very cool and effective tool, and that it can
>actually be used in a stable production environment is definitely not
>something I
>want to miss, but maybe that is not so much due to a strict development
>as it is due to the skills of the core developers in spotting bogus
>changes ;)

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? :)

>Just a thought...

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.

>Maybe I got the wrong impression on just how things are done
>by the twisted team.

You seem to have a roughly correct impression.  Tests and documentation are required before a patch will be accepted.

>BTW, the patch in ticket #1794 is already included in 2.5, it probably
>shouldn't be an active ticket anymore.

Thanks for the heads up - it looks like Thomas Herve closed it in response.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/twisted-python/attachments/20070112/904e912e/attachment.html>

More information about the Twisted-Python mailing list