[Zope-dev] the Zope Framework project

[Martijn Faassen]

Hi there,

On Wed, Mar 4, 2009 at 6:26 PM, Chris McDonough <chrism at plope.com> wrote:
> Martijn Faassen wrote:
> <snip>
>
>> * A clear set of explicit, layered dependencies in software is generally
>> a good thing. We can start thinking about smaller pieces better. By
>> splitting up into individually packaged and released bits, we are forced
>> to think about these things more.
>
> (I'm running out of steam on responses here.  This will likely be one of the last).
>
> You've been saying this: "we'll just identitfy and maintain this giant set of
> versions for backwards compatibility purposes and for purposes of *moving
> platforms forward through time*".  But you also seem to be saying  "*real soon
> now* we'll also be making hard choices about the life and death of things that
> make up the 'framework' and evaluating each on its merit as an idependent
> entity."  Personally, I disbelieve that this "real soon now" will ever happen
> without having it as the *primary* and maybe the *only* goal.

It can't be the only goal, we also want to build new stuff, right?
Anyway, cleaning this stuff up is one of my most important goals for
me personally; I and 5 others spent a week of our life doing that a
month ago.

Real soon now, zope.app.container and zope.app.folder and
zope.app.keyreference and zope.app.catalog are not going to be the
business of the Zope Framework developers anymore. They contain ZMI
stuff the Zope Framework developers do not care about directly and
will only care about indirectly if enough people speak up for it and
are willing to work on it. I hope many of them join the real soon now.
We have a line behind which I, and many others, don't have to care
anymore. A receding line, leaving many things behind.

I don't want to stop anyone else from caring about these other things.
I can't anyway. If people do get together who want to develop "Zope 3
the app server" they should get together and organize. I hope I can
convince them that this line is important and I hope I can convince
people in general to care *more* about the stuff in the Zope Framework
than anything else. The ZMI isn't the main thrust of Zope 3
development, and hasn't been for a long time anyway. I want to stop
having to worry about it as soon as possible, and am willing to do
work to get there.

> I believe to get success here (measured as gaining new Python developer users),

I think success is not just python developer users, but also serving
current users in the Zope 2, Zope 3 and Grok worlds better by having a
more comprehensible platform.

> our path forward needs to be way, way, way more radical and needs to involve
> making hard choices that treat individual packages on their own merit rather
> than even considering their role as part of a larger collection.  That's the
> bottom line and I believe it's our fundamental point of disagreement. IMO, the
> part a package plays as part of the larger collection should be utterly and
> brutally subservient to its merit as a standalone package.

Look, I know you are not using the packages the way that I am, but
can't we work together? I want these packages to make sense
stand-alone very much, but I also need to consider them as part of a
whole that needs to be managed.

> Also IMO, if there
> were absolutely no list of versions known to work together, but each piece
> worked on its own and had merit on its own, we'd be in a far better place as far
> as attracting new users.  Any list of packages-known-to-work-together should be
> a "oh, by the way, this might be handy", not the raison d'etre of the group and
> this discussion.

I think the group needs to have a list of packages it cares about, so
we know what we're talking about. That way we know which packages we
need to document and present and clean up, and we know *what* code we
want to move out of packages that are in that list. And none of these
packages can be broken so they *need* to work together! And we also
present a list of versions that we have tested together as a service
to the people who need such lists.

If we *don't* make such a list we'll remain in the limbo where *all*
packages are of some nebulous importance.

>> I don't see this as at all incompatible with a group managing a list of
>> versions that is known to work together, as a service to various groups
>> which do need such lists anyway.
>
> Maybe not.  But as far as I can tell, maintaining such a list is just business
> as usual and doesn't require any proposal at all.

We're maintaining a different list now, for the Zope 3 app server that
you install. What's in the list is mainly just inertia and ad-hoc
decision making. That's not the list I'm talking about, though
there'll be tremendous overlap to start with. I'm proposing not just a
different list but a community that cares about those libraries.

Regards,

Martijn