[Zope-dev] Next steps on Zope 2.6 plan

[Chris McDonough]

FWIW, I think a better Zope install is desperately necessary, and since
there's a fishbowl proposal and a willing contributor (you), IMHO it's a
no-brainer.. the biggest hurdle is keeping you happy and willing to write
code and docs. ;-)

That said, since we don't have a less centralized or formalized process in
place, it will likely boil down to some sort of straw poll on the lists with
Brian having veto power as to what is reasonable to shoot for for 2.6 and
that will dictate which proposed features will be accepted.  Fun. ;-)

----- Original Message -----
From: "Matt Behrens" <matt.behrens@kohler.com>
To: "Brian Lloyd" <brian@zope.com>
Cc: <zope-dev@zope.org>
Sent: Thursday, March 21, 2002 7:53 AM
Subject: Re: [Zope-dev] Next steps on Zope 2.6 plan


> 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.
>
> _______________________________________________
> Zope-Dev maillist  -  Zope-Dev@zope.org
> http://lists.zope.org/mailman/listinfo/zope-dev
> **  No cross posts or HTML encoding!  **
> (Related lists -
>  http://lists.zope.org/mailman/listinfo/zope-announce
>  http://lists.zope.org/mailman/listinfo/zope )
>