Hash: SHA1

On 04.03.2009 7:52 Uhr, Chris McDonough wrote:
> Tather than reply in kind here, let me summarize:  I'm glad we agree more than
> we disagree, and I apologize if I've attributed to you beliefs that you don't
> have.  It's heartening to hear that you're in favor of most of the things I'm
> also in favor of.  But we do have real differences in opinion I think.  I'd
> rather be constructive than obstructionist here: at the end of each item 
> below I
> ask for an opinion based on a suggestion.
> 1)  I'm not in favor of a single steering group for the *entirety* of all Zope
> software.   We've tried a similar thing in the past (via the foundation
> structure); it didn't work and I'm not sure how we'd expect things to turn out
> any differently this time.  Instead, perhaps the focus of groups should be on
> some much smaller subset of Zope-related software (e.g. the
> zope.interface+zope.component group, the zope.schema group, the ZODB group,
> etc).  Could we consider this?

This would definitely make sense to me. With respect to a steering
committee: I am also a bit skeptical about such a committee. I think
that the upcoming ZF board will have a good representation of each Zope
project on the board in order to address things on the board level.

> 2) I'm also not in favor of a giant lockstep set of software versions shared
> between notional releases Zope 3.5, Grok, and Zope 2.12.  I can only see this 
> as
> continuing our mistakes of old by trying to treat some collection of software 
> as
> "Zope" as opposed to letting parts of it survive or die on their own based on
> merit; it'd be more effective to just let each framework use (or disuse!)
> whatever versions of stuff that work best for it.  That's why the software is
> broken out into individual components in the first place; we should encourage
> diversity in component usage.  Instead of trying to legislate and bless some 
> set
> of components as a "version", we should just work to make each piece better 
> and
> worthwhile to use independently; it's value would be in its actual usefulness
> rather than some belief that it works well with the other components in the
> "version".  Could we at least agree that lockstep versioning of a huge set of
> Zope eggs to be shared across many frameworks is not optimal for the long term
> and that it would be better if each framework could pick and choose whatever
> components and versions it actually needed?  Could we also agree that this 
> would
> tend to result in better dependency partitioning ("X depends on Y, I don't 
> need
> Y, I just need X, let's fix that")?

A central maintained KGS for Zope 3.X components is necessary since only
a minor number of core developers knows exactly which version match
together. You can not expect that non-core developers have this
knowledge. I agree on the point of making the components having their
own lifecycle and to make them usable more independently.

Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

fn:Andreas Jung
org:ZOPYX Ltd. & Co. KG
adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany

Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to