-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adam GROSZER wrote:
> I think we need some sort of stering group (or person(s)). > Without rules and decisions to follow we're going to end up like headless > chicken running around in the kitchen. Noone knows the direction. > > Yes sometimes radical changes are good. We're also carrying a lot of old > baggage around with Zope3. > It is lurking around the corner. Like Shane's zope.pipeline, repoze > stuff, etc. > BUT at the same we have projects that have to be kept running (and > migrated, possibly smoothly) > > Keeping our packages together at least with a KGS is a must in my > opinion. Unless you want yourself to find a working set between the > permutations of all required packages versions. > Someone releases a new package version and your project just break the > next day. That's a nightmare. It is a nightmare, but not one which a KGS can really fix: sometimes your project needs its *own* KGS. Honestly, the only safe thing for anybody trying to support a large application in production is to run their own index, and do the gatekeeping of packages into it themselves. For instance: - - How many projects are there (community efforts, as well as individual sites / applications) need updates to some of the packages traditionally part of a Zope3 release? I would bet that there are lots of such projects. - - How many projects are there which are going to need a "Zope 3.5" release (as opposed to updates to some of the packages traditionally part of Zope3)? I would bet that this set is smaller than the first. For instance, I know that Zope 2.12 *says* it will rely on 3.5, but I don't know what that means, actually. Grok already maintains the moral equivalent of its own KGS, right? - - How many need *all* of Zope3, including the ZMI? I'm betting that set is much smaller than either of the others? - - 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 need to create something more like self-organizing mini-communities around the various packages (or maybe sets). 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? 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 interesting. 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. 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 iD8DBQFJrCaj+gerLs4ltQ4RAj6QAJ42IfLM5qaEtexebr1FqYW6kG6fmACgk2Lq aKGj9xT5QmUpVKYpV0HeBoQ= =S9Gg -----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 )
