-----BEGIN PGP SIGNED MESSAGE-----
Martin Aspeli wrote:
> Tres Seaver wrote:
>> - - 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
>> 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.
>> I'm not so sure that any other package is going to be as widely
> 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
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 Seaver +1 540-429-0999 tsea...@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
-----END PGP SIGNATURE-----
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -