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. 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 this discussion. > 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. - C _______________________________________________ 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 )