[Zope-dev] the Zope Framework project

[Andreas Jung]

-----BEGIN PGP SIGNED MESSAGE-----
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.

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

iEYEARECAAYFAkmuKckACgkQCJIWIbr9KYwyVQCg4wa+BwWKTR++sHQGJRlD7K6/
C3cAoMgUSnynhrno3ja+m9Bf8wYJb9w1
=P85M
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lists.vcf
Type: text/x-vcard
Size: 316 bytes
Desc: not available
Url : http://mail.zope.org/pipermail/zope-dev/attachments/20090304/a721a536/attachment.vcf