So I've volunteed to do backports from trunk to the stable (currently 2.0.x) branch for important fixes. "Important" is up for discussion, but here's what I'm thinking: Important means one of: 1) installer brokenness 2) fixes a regression 3) fixes nonfunctional new API Also (and this is not really up for discussion): 1) patch must be small (and correct). Even if it meets one of the above criteria, if it is a large or non-obviously-correct change, I don't want to see it. 2) must not add APIs. 3) if it's been broken for a long time (e.g. in the 1.3 release), it can stand to be broken a little while longer. I'll watch for things I think are appropriate, but, if anyone else wants to point out some svn revisions of changes they think would be appropriate, that's fine too. Now, before people start suggesting that every change be backported (which obviously isn't going to happen), we probably ought to set a goal for the next "real" release (2-3 months?). I expect the 2.0.1 release should go out this week sometime. I think win32 build fixes ought to land first, but that's about all I know of. I'd also love to include the changes to the release scripts which will allow the version to exist in the __version__s in the SVN repository instead of being specified on the command-line by the person releasing. Having consistent versions is important. Someone just needs to write those changes first. However, that doesn't affect the released tarballs at all, so it's not really necessary for before-2.0.1. Here's what I did so far:

Log: Backports from trunk: 13307 (twisted/topfiles/README) - we support 2.4 too 13324 (twisted/internet/defer.py) - [947] Fix DeferredQueue backlog/size limit. 13354 (twisted/plugins/__init__.py) - Correct maintainer address. 13355 (twisted/test/test_defer.py) - improvements to DeferredQueue test case 13387 (setup.py) - add news to list of subprojects

James