Brian Lloyd wrote:
One suggestion Casey had was to start to codify a set of rules that features have to abide by to be considered for inclusion.
Hmm, these rules seem to have several thinly veiled references to my pet project. :-) I do firmly agree with the rules in spirit, but I think a little clarification/discussion is in order so it doesn't get cut without good reason.
- A feature release should never contain more than one blow-it- up-and-redo-it type project (such as radical changes to key parts of packaging or infrastructure). For example, it would probably be a bad idea to totally redo the ZODB, packaging and installation and the security system all in one release (unless it is a major release like Zope2 -> Zope3).
Agreed. I think it is important to note two things, though: 1. Creating the new, recommended installation procedure is different from gutting and replacing an existing feature, simply because we don't really *have* a recommended installation procedure right now. As currently proposed, you can still use Zope 2.6 just like you used Zope 2.5, except you'll type 'make' instead of 'python2.1 wo_pcgi.py'. 2. I've tried to keep this proposal clean enough that it can easily be brought into Z3, so that instances of Z2 and Z3 on the same system can be controlled and managed by the same software.
The aggregate impact in terms of obsoleting existing knowledge and documentation is too great to do many of these at once. It takes time for users and developers to catch up after something major is refactored, and we need to keep this in mind.
Just to reiterate, they'll have all the time they need. The only people I see scrambling to get up to date are Zope 2.6 packagers (like myself). Perhaps a qualification is in order here, i.e. mitigation of this effect by maintaining as much backwards compatibility as possible.
- Features or components added to the Zope core should address a clear and generally agreed-upon need. Otherwise, accumulation of components over time will become a significant support burden for the zope maintainers.
My proposal will probably reduce support burdens. Just the other day, on IRC, we had to tell someone to switch away from his nicely packaged RPM version of Zope and use the source distro. So maybe this should be a qualified rule as well?
Thoughts? I'll volunteer to maintain the guidelines document on dev.zope.org if folks can send their guideline suggestions.
I don't know if the above constitutes useful information for writing rule changes or not, but I hope it's helpful.