[Zope-dev] the Zope Framework project

[Tres Seaver]

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

iD8DBQFJrCaj+gerLs4ltQ4RAj6QAJ42IfLM5qaEtexebr1FqYW6kG6fmACgk2Lq
aKGj9xT5QmUpVKYpV0HeBoQ=
=S9Gg
-----END PGP SIGNATURE-----