-----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 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 iD8DBQFJrU4N+gerLs4ltQ4RAuFaAKC2eBkntSauZvi0qWm5wgAvuwVD+QCgxIa8 y8wKdscbD9+f4bfyq+42yfM= =71WM -----END PGP SIGNATURE----- _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )