Glyph Lefkowitz email@example.com writes:
While I currently believe that Tubes's API has firmed up and its current API is suitable for general purpose use, I have believed that at various points in the past as well when it was completely wrong. This sentiment is very much of the "this time for sure!" variety, and I will [...] In this case, I actually want the twisted compatibility policy to apply.
These two points seem to be somewhat conflicting.
So I am keenly interested in ways to address this problem rather than to work around it. If we are going to try to develop new big Twisted features outside of Twisted, maybe that's a good idea, but then we need a modified code-review policy for accepting those projects back in where they going to be subjected to code-review standards during development rather than in one giant burst at the end.
This seems like a reasonable thing to do. If all the code has been subject to review according to twisteds procedure, then it would seem to be reasonable to require that the changes needed to move the code in to twisted would need to be reviewed (so moving files around and adjusting imports and the like).
Even if my opinion were inverted on all of the points above, I really want to avoid doing this - I especially want to avoid the part where it somehow doesn't work on Twisted's heterogenous CI system when we try to reintegrate it after apparently working on some other one-version-of-linux CI infrastructure for some time :).
It would certainly be possible to hook twisted's CI system to additional projects.