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
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/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
Set up buildbot to run application packages against both last-released
core and most-current core.
My way is:
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.