[Twisted-web] Actual Useful Post

[glyph at divmod.com]

Going back over the recent thread that everyone else has probably already killfile'd, I have extracted several useful points, and I will present them here detached from the other thread so they don't get lost in the noise.  The fact that I took exception to the presentation of these ideas doesn't mean that the problems aren't real.

#1, something for the Twisted team to do

The bugtracker(s) need to be kept in a more up-to-date state.  If a patch has been stalled for lack of tests, it should be very clear that it's been stalled for lack of tests so that people can write some.  For lack of a better convention, maintainers, please look at your bug-lists and make sure that the status is "need-eg" (in roundup) or it has the keyword "testblocked" (in trac) if they need more tests or an explanation.  There is a stark difference between tickets which might not receive attention because the maintainer doesn't have any time, and tickets which definitely won't receive attention because other tickets that have tests already, or are in the maintainer's interests, are higher priority.  This will also make it easier for people who don't want to submit tests to submit patches and have a mechanism for test fanatics to contribute tests to those fixes they want merged.

In trac I have also tried to mark tickets with "low" or "lowest" priority if they are tickets that I would prefer someone to steal from me.  I would suggest that others do the same.

#2, something for the community to do

Twisted, and Twisted's web-related projects should have more regular releases, so that other projects don't need to track them or deal with self-installed monkeypatches any longer than necessary.  Although I've defended this practice, and I do think that it's a requirement of the practical necessity of providing the community with stable releases, it's *not* ideal; if everyone were running apt and we had a dedicated package maintainer and a mechanism for strict backwards compatibility verification, I'd want to update every copy of Twisted in the world when we fixed a bug.

What we need to do a stable release of Twisted is fixes for the few release-critical bugs, and then user-testing of the package.  Normally the release manager does this, but the more feedback we have, the surer we are that the package is ready to go, and the less that the release manager has to do.  You can help out by looking at the 'admin/subproject.txt' in Twisted.  Make a release using the technique described there, run the unit tests, use some applications, and verify that whatever code you've written using Twisted is still working.  Look over the SVN log for noteworthy changes and help write a NEWS file that summarizes them comprehensibly.

Anything that turns the buildbot greener also increases the chance that a release will be forthcoming.

I am lead to believe that Chris Armstrong (our GLORIOUS release-manager, hallowed be his name for all time, amen) is going to be putting together a release this weekend.  I hope he will post a followup that includes more detailed instructions.  (Hint, hint.)