Antoine, I'm very happy that you've decided to help Twisted get going on Py3.  I see that you've already submitted several of your fixes to the Twisted tracker.  Thanks for that. We'll try (as always) to get those reviewed soon.  We do eventually want to have 3.x support in trunk, so anything you're doing to support that goal should be an acceptable patch - provided it meets our other quality criteria, of course, but there's no patch for py3k support which shouldn't be able to meet that criteria :).

I would suggest that you submit all patches directly to the Twisted tracker, where they can be properly reviewed before landing, not to this (or any other) fork.  As several other messages in this thread have indicated, it looks like you may be misunderstanding a few key aspects of Twisted (such as how the distinction between bytes and unicode needs to be treated in the Banana protocol), so this fork is going to get some things wrong, potentially with wire-level implications and incompatibilities.  Review discussions of targeted patches will allow us to address those areas individually, while getting the other parts merged into the mainline.

(This goes double for other people who are not Antoine wanting to help out: please look first at this list of tickets: <http://twistedmatrix.com/trac/query?status=assigned&status=new&status=reopened&group=status&milestone=Python-3.x>, and help them get through the review process, rather than submitting patches to a fork.)

Most importantly, it will not be reasonable to merge in a humongous branch with hundreds of unrelated changes later; doing code review on changes that big just isn't feasible and chances are good that they will linger forever.  If your fork _is_ made to work correctly, folding that correct behavior back in with all the necessary test coverage and fixes will be a much larger job than doing it the right way in the first place, one bit at a time, in Twisted trunk.  We have had several bad experiences with this kind of development before and I would rather not repeat them.

Finally, having the code in mainline will allow it to be subjected to our correctness testing <http://buildbot.twistedmatrix.com/> and also our performance testing <http://speed.twistedmatrix.com/>, neither of which is a small effort.

If this is just a short-lived experimental test bed to try things out quickly (i.e. a spike to demonstrate that it's feasible to get Twisted on py3), then that's fine, but I am somewhat concerned that impatient users will actually adopt this fork, and we will have to spend a lot of energy telling people (A) "don't use Antoine's fork, it's broken", and (B) "please stop reporting bugs in this broken fork on our bug tracker".

At any rate, the very first step here should be to add an as-yet-unsupported py3 builder to our build farm.  This should be pretty straightforward, as new builders are added all the time, and we have some new hardware that could be put to use for this.

Alternatively, we do already have a py3k-warnings buildbot set up; you can see the current warnings here: <http://buildbot.twistedmatrix.com/builders/python-3k-warnings/builds/111/steps/trial/logs/stdio>, although possibly this needs to be updated to python 2.7 to get rid of irrelevant noise like warnings about callable() going away, since I believe it's come back to 3.x now.

We might also be able to help with your problem of testing things on Windows, as we do have several Windows test machines set up already.  (Is pywin32 supported on 3.x yet?  <http://pypi.python.org/pypi/pywin32/> doesn't indicate.)

As you can see on <http://buildbot.twistedmatrix.com/builders>, we already even have some buildbots running python 3 builds for PyOpenSSL, so this isn't even really anything new.

Would anyone like to volunteer to help out with Antoine's efforts on the build-infrastructure side of things?