RE: [Zope-dev] Next steps on Zope 2.6 plan
> > 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. Of course. Note that my references were not (and were not intended to be, veiled or otherwise :) knocks on your proposal or any _particular_ proposal. My point was to say that one "big" change should be the limit for any given feature release. This can be a helpful guideline for the future: if as a developer you know that "total security rewrite" is already on the list for some feature release, then you can be pretty sure that you'll have a hard fight to get some other major change into the same release. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] Next steps on Zope 2.6 plan
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" <[EMAIL PROTECTED]> To: "Brian Lloyd" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> 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 - [EMAIL PROTECTED] > 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 ) > ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
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 - [EMAIL PROTECTED] 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 )
