[Zope-dev] the Zope Framework project

[Chris McDonough]

Lennart Regebro wrote:
> 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?

To the extent we can discourage the formation of the
one-big-group-to-rule-them-all by encouraging the formation of smaller groups, I
think it's a good idea.  But in reality, I think nothing needs to be done:
group-forming will always be a self-selecting process.

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

This just seems like a blindingly obvious antigoal to actually breaking apart
the software into more discrete bits using eggs.  Why not just stick with a huge
tarball release or one single egg if it all has to be versioned through time to
99% of its consumers as one giant collection of software treated as a unit?

> If Repoze.bfg doesn't want to lockstep, the Zope2/Zope3/Grok lockstep
> would not pose a problem for Repoze, would it?

Nope.

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

Right.  No one except people who've already bought in to the notion of Zope
software as one huge pile will benefit from the lockstep centralized planning.
It won't gain Zope any new users; no different framework users will begin to use
Zope software as a result of this plan.  How is this different than the current
status quo?

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

It doesn't pose a problem.  It's just business as usual.

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

When components are not treated as one giant pile, and it's expected that you
should be able to use pieces of the pile selectively without buying in to some
unrelated software, dependency management becomes far more brutal and realistic.

- C