[Zope-dev] Next steps on Zope 2.6 plan

[Matt Behrens]

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.