[Twisted-Python] On splitting Twisted into subprojects
mary-twisted at puzzling.org
Sat Apr 17 08:35:42 EDT 2004
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
It seems like the twisted-web project are planning to split off fairly
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:
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.
More information about the Twisted-Python