[Zope-dev] the Zope Framework project

[Lennart Regebro]

On Wed, Mar 4, 2009 at 07:52, Chris McDonough <chrism at plope.com> 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?

It's better certainly, but isn't this small enough in itself that
these groups will form naturally by whoever is working on it?

> 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".

I'm pretty sure Zope 2, Zope 3 and Grok wants to go in lockstep if
possible. I'm just pondering the nightmare of working having say Zope
3.4 with one API, and Zope 3.5 with a subtyly different API, and Grok
1.0, with yet another subtly different API and Grok 1.1 with another
subtly different API and Zope 2.12 with yet another subtly different
API and Zope 2.13 with yet another subtly different API. Urgh.

No, we want Zope 3.4 to have one set of modules with one API, and Grok
1.0 and Zope 2.12 to use exactly the same. And then a Zope 3.4 with a
Grok 1.1 (or something) and a Zope 2.13. So we DO want "lockstep" and
to use the same major KGS over all these versions. At least I do I
don't see why this must result in parts that should die being left
undead.

If Repoze.bfg doesn't want to lockstep, the Zope2/Zope3/Grok lockstep
would not pose a problem for Repoze, would it? Then again, if Repoze
doens't want to be a part of The Zope Framework users but always make
their own set of modules, that will admittedly lessen the purpose of
it, as the minimalistic attitude of Repoze.bfg would work as a good
test of what should be in the framework in the first place.

> 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

Well, since it's shared by many frameworks, I'm not sure it would be
"huge". But that's a matter of taste of course. But in any case,
through this discussion, I must admit that I not not understand why
this would pose problem.

> and that it would be better if each framework could pick and choose whatever
> components and versions it actually needed?

It can. These are not mutually exclusive. A central KGS for the core
framework does not exclude you making your own KGS, neither does it
mean you can't release each module separately.

> 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")?

I don't see how these are related.

-- 
Lennart Regebro: Pythonista, Barista, Notsotrista.
http://regebro.wordpress.com/
+33 661 58 14 64