[Twisted-Python] removing unsupported reactors in twisted 2.6: qt, corefoundation, threadedselect, wx

[glyph at divmod.com]

There are a few reactors in the twisted codebase which currently have no maintainer and do not pass the test suite.  I've listed them in the subject of this message.

I'm comfortable to leave half-supported or potentially broken reactors in the Twisted distribution, as long as they were clearly marked as such and there was some at least potential path to making them work.  IOCP, for example, is good enough for many uses despite not passing the full test suite (and there are rumours of a new buildbot for it appearing soon...)  However, leaving a pile of known-to-be-broken and unmaintained reactors in Twisted is just going to give the impression that Twisted is buggy, and increase the amount of dead code that people reading the codebase can be confused by.

The reactors presented in the subject all seem to have been abandoned.  Even our friends at Apple are mainly concerned with the use of Twisted for server work, and while they've been attempting to help us find someone to poke around GUI <-> reactor integration on OS X, it's not their area of expertise.

At this point, I believe that setting up a buildslave for any of these reactors should be possible with our existing build infrastructure.  Of course, contributions of additional buildslaves are always welcome :), but we can set up slaves for wx and corefoundation ourselves if someone is going to actually start trying to fix them.

I know that there are people in the Twisted community integrating it with wxpython and qt.  I'd really like it if someone could commit to at least contributing some patches in the future.

If I don't hear anything on these fronts before the Twisted 2.6 release, those reactors will be removed from SVN trunk at HEAD and not be included in the 2.6 release.  (The next planned release is Twisted 2.5, so you still have some breathing room.)

Currently qtreactor is being tested on the "reactors" buildslave and is keeping it red, despite the fact that all the other reactors on that slave work fine (modulo a few elusive race conditions).  wxreactor is not being tested at all.  I believe we should split qt out so that it can have its own red column and not interfere with the gtk and poll reactors, and if we run a wx slave it should also be separate.

Although I know of Qt and WX users, I do not know of anyone currently using the corefoundation reactor in an application.  Are you out there?  Is it being used?

The last word I heard on the corefoundation reactor was from its author, Bob Ippolito, who suggested that it was not the correct way to integrate Twisted with GUI applications.  However, his suggested replacement (threadedselectreactor) is buggy, also unmaintained, and IMHO misdesigned, so in the absence of other knowledge I believe that continuing to provide some corefoundation support would be the best way to support the mac.  After receiving a shiny new computer from them I feel inclined to do the best job possible to support Apple's platform, but I simply don't have the time, knowledge, or energy to do the development myself.

With the aforementioned hardware, I believe it would not be much trouble for us to set up a corefoundation reactor buildslave of our own, but we still need someone who will actually work on fixing the bugs, otherwise, the code should be removed.

threadedselectreactor is an interesting concept but hopelessly broken and untested in its current implementation.  I believe it should definitely be removed as a reactor of its own, although as a supporting basis for other reactors it might be good to leave around.  While not entirely correct, it is certainly _less_ broken than the previous ghastly attempt at a wxreactor.  I think it would be a good idea to remove threadedselect from the reactors list in Twisted 2.6, although if someone wants to convince me otherwise with a use-case (and a similar promise of future patches), I'd be happy to hear it.

Once all these reactors have dedicated buildslaves and pass the tests, it is far less important that we have dedicated maintainers.  We can simply insist that all future commits keep all the buildslaves green.  I say this because I want to be clear that I am not asking for a lifetime commitment or we are going to instantly desupport your platform: I'm asking for help getting to the point where we can support multiple platforms without having to be experts in all of them.