I was confused by the recent discussion of the recent tmlabs.* hierarchy, so there was a long discussion on IRC tonight about how exactly the various splits are going to proceed. We almost reached a consensus about how things should work, except foom (James Knight) managed to win the argument about how it should work eventually. However, I'm more irritating than he is, so we're still doing things my way. To recap, James's way, which is similar to what was discussed on the list before, is: Keep everything in the same repository, but provide different top-level directories for Twisted and the new split-off packages, e.g. svn://.../trunk/Twisted/twisted/internet/..., svn://.../trunk/TwistedNews/twisted/news/... (previously we were going to keep everything in different repositories, but we agreed that this was unnecessary and came with several unpleasant restrictions) Move code in new subdirectories to the tmlabs.* hierarchy for marketing purposes because it provides a cleaner separation between core and applications. However, I feel that there are lots of other hierarchy reorganizations that are potentially a good idea, and this is another step. Set up buildbot to run application packages against both last-released core and most-current core. My way is: For now... The repository mostly stays how it is. Buildbot keeps running against trunk, but against a series of application packages instead of twisted.test. Package names do not change. Eventually, one or all of these may need to change. However, all that will be happening to split out packages is: Modules in protocols/, test/, and tap/ move to an appropriate top-level package, with backward-compatibility wrapper. The release script will be changed to generate separate tarballs for various top-level packages. We will create a topfiles/ directory or somesuch to contain READMEs, setup.py's, etc., for each subproject. Barring any strong objections, this smaller, simpler plan is now how the releases should proceed. We do still intend to do new websites and download areas for each subproject (sorry maintainers, you're not getting out of writing HTML!), just not new repositories. Hopefully this will be a bit easier on users as we will get decoupled release cycles, but aside from protocols moving, it should require no code changes to remove all import-related deprecation warnings. The main point in this change in plan is to avoid doing too many things at once, to make sure that the whole split finishes before someone implements some crazy new features. Therefore, issues such as how to version APIs, re-organize modules, or re-name packages will be addressed *after* the appropriate changes for this split have been prepared, but feel free to discuss them beforehand. I will be replying to James's setversion proposal soon.