Martijn Faassen wrote:
> * 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
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.
I believe to get success here (measured as gaining new Python developer users),
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. 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
> 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.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -