[Zope-dev] the Zope Framework project

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Aspeli wrote:
> Tres Seaver wrote:

<snip>

>> - - How many need *all* of Zope3, including the ZMI?  I'm betting that
>>   set is much smaller than either of the others?
> 
> Probably none. So having better dependencies would obviously be good. I 
> think you still need a KGS of sorts, but you don't need to depend on 
> *all* of it. :)

I'm sure that the set is bigger than that.  However, I want to identify
the critical subset the *everybody* needs, and ensure that we prioritize
"steering" efforts there:  the other packages can mostly just be left in
the hands of the disjoint groups that need them.

>> - - Of the first set, what is the likelihood that different projects
>>   will have conflicting goals about the direction of one or more
>>   packages?
>>
>> Given the likelihood that a monolithic Zope 3.5 release is not
>> interesting to lots of the folks who both develop and consume its
>> packages, how much coordination is going to be possible (or even useful)
>> around the idea of another release?
> 
> Maybe we could identify some "vectors" down the dependency graph that we 
> *do* care about. If we analysed our projects (Plone, and a bunch of 
> add-on products, for instance), we could probably manage to maintain 
> KGS' that say "if you want the container interfaces, these packages are 
> known to work together".

I suggested one such vector (zope.interface, zope.component).  Another
one is "the packages which Zope2 (really) needs."


>> Maybe we need to create something more like self-organizing
>> mini-communities around the various packages (or maybe sets).
> 
> Heh... right. ;-)
> 
>>  E.g., I
>> would bet that almost everyone active on this list has a stake in
>> zope.interface, zope.component, and their dependencies.  Note that *two*
>> of the remaining dependencies (zope.deferredimport, zope.deprecation)
>> are only there to deal with BBB isssues:  maybe they should go?
> 
> Why? They're tiny, and BBB is good. No piece of framework code can be 
> taken seriously if it pretends that people are not going to need 
> backwards compatibility.

Some BBB may be worth keeping:  I have argued before, however, that the
specific BBB strategy which requires those three packages is not a big
success:   rather than proxying all modules with deprecations, for
instance, I would rather just leave the BBB imports in place *forever*,
without emitting warnings.

>> Another, zope.proxy, is a blocker for using the packages on non-CPython
>> platforms:  should it go?  If we consider those packages *in isolation*,
>> as things potentially useful outside any larger framework, the answers
>> to those questions might be different.
> 
> True.
> 
>> I'm not so sure that any other package is going to be as widely
>> interesting.
> 
> I can think of a few: the container stuff, browser views and pages, page 
> template files, for example.

We already have "successful" forks for a number of those.

>>  I also think that having the *whole* Zope community do
>> oversight oversee on the rest is less useful than having the folks with
>> "skin in the game" for a particular package steer it.  I am unlikely to
>> care much about anything in the Z3 ZMI, for instance, or about a number
>> of other packages in our various namespaces:  I could do my job better,
>> *and* keep from interfering in others' interests (e.g., the "stop
>> energy" Chris mentioned), if we separated out the various areas of concerns.
> 
> True. However, someone still needs to think about whether these things 
> are pulling in the same direction, or becoming incompatible with one 
> another.

Note that divergence may be an acceptable outcome, here, especially if
we adopt the pattern that fundamental disagreements on the direction of
a shared package can be resolved by the "amicable divorce" of a fork.



Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJrU4N+gerLs4ltQ4RAuFaAKC2eBkntSauZvi0qWm5wgAvuwVD+QCgxIa8
y8wKdscbD9+f4bfyq+42yfM=
=71WM
-----END PGP SIGNATURE-----