[Zope-dev] the Zope Framework project

[Lennart Regebro]

On Wed, Mar 4, 2009 at 09:21, Chris McDonough <chrism at plope.com> wrote:
> 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.

Well, at least we should try this first, I agree with that.

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

But it doesn't have to be treated as a unit. I don't know what you
mean with "version through time to 99% of its customers". To me having
releases of modules and releases of sets of modules is orthogonal and
does not contradict each other.

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

I have the feeling that either you or me have completely misunderstood
the proposal, because I don't think you are talking about the same
proposal as me.

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

Yes. And I still do not see how this is related to the proposal. It is
expected that you should be able to use pieces of the pile
selectively, and it will continue to be expected.

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