[Twisted-web] On splitting Twisted into subprojects

[Mary Gardiner]

    Note: Cross-posted to twisted-web and twisted-python. Decide between
    them for your follow-ups please :)

This is intended to spark a little more discussion on splitting Twisted
into subprojects, as discussed on Aussie-time on IRC (Jerub, jml, spiv
and myself).

It seems like the twisted-web project are planning to split off fairly
soon: see
http://twistedmatrix.com/pipermail/twisted-web/2004-April/000312.html

It's pretty likely that this split will go ahead without any kind of
imposed-from-above decisions about where the website will go, what the
release cycle will look like, where the docs will move to, what the
status of shared docs will be (I tend to focus on docs...)

The nightmare scenario for splitting twisted into subprojects is that
every subproject develops its own release code, release procedures,
testing framework, website, documentation style, community, policies...
etc etc. And shortly after that we all spiral into the sun or something.

There appeared to us to be three possible ways of avoiding this:

 1. Luck

 2. Release code, release procedures, testing framework, website,
 documentation style, community, policies... imposed from above

 3. Twisted Web (or whatever other project splits first) acting as a
 "model split": evolving release mechanisms, policy etc etc that are
 fundamentally sane and wonderful so that noone would think of doing
 things any other way.

Since 3 looks like being the most achievable, this is basically an
appeal to the twisted-web folk to keep in mind that they should, where
possible, try and make twisted-web the Model of a Modern Twisted
Subproject. And make it as easy as possible for other subprojects to
copy whatever it is that they're going to do.

I personally would like to offer my help in documenting subproject
procedures as they evolve, and storing that documentation in some kind
of prominent place.

-Mary