-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hanno Schlichting wrote: > Good morning :) > > On Sun, Dec 27, 2009 at 5:11 AM, Martin Aspeli <optilude+li...@gmail.com> > wrote: >> 2009/12/27 Hanno Schlichting <ha...@hannosch.eu>: >>> The Zope Toolkit is explicitly not a framework or application server - >>> it shouldn't contain any zope.app packages, neither directly nor as >>> test dependencies. Zope2 trunk which is based on the real ZTK doesn't >>> use any zope.app packages anymore. So I don't want to buy into the >>> maintenance burden of zope.app any longer. >> I get that, but on balance dropping zope.intid from the ZTK seems the >> greater of two evils. I'd rather it was left in with some hair >> *test-only* dependencies until we have time to refactor it, rather >> than drop it until such time, because: > > The specific way we set up the ZTK causes all dependencies of a > package to become part of the ZTK version list. If we leave zope.intid > and catalog in, we also need to leave the 36 zope.app packages they > depend on in it. With those two being the last packages causing this > problem, I think it's reasonable to turn the responsibility around. > Those who are specifically interested in these two packages should > make sure they behave. Once they do, I want them to be part of the ZTK > again. But at this point I'm not willing to have two packages incur a > maintenance burden of a large part of zope.app on toolkit developers > anymore. > >> - Consumers of the ZTK are using zope.intid in the wild right now > > Well, kinda. Neither repoze, Zope2, CMF or Plone actually use it in > their core, only Grok does - but that's not the point ;) > >> - Since it was renamed from zope.app.intid to zope.intid, I think >> there's been an expectation that this was a "safe" package to depend >> on; removing it from the ZTK implies a smaller group of people who're >> willing to help maintain it > > It's a perfectly save package to depend on. But it needs people who > want to maintain it, not force everyone who has an interest in the ZTK > to maintain it.
The whole point of breaking the monolith up was to allow for different maintainers, release cycles, etc. Pushing non-conformning packages out of the ZTK does *nothing* to harm the current users of such packages: it just signals the (already existing) condition of (non)maintainership of those packages. >> - Centralised unique id management is an important category of >> service that is likely to be more useful if there is one canonical >> implementation that "everyone" can depend on - if different consumers >> of the ZTK end up inventing their own approach to this use case, that >> will likely detract from cross-framework reuse > > Sure. It should be in the ZTK, I don't argue against that. But it > needs to play by the rules before it gets to be part of it. Amen, brother! 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.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAks29ooACgkQ+gerLs4ltQ4bDgCeNaWLIhWsIaAn87lqKiIw3Chc Z7EAn1B28ytkCiNcVWepvJvb1GZdLHgR =OU5p -----END PGP SIGNATURE----- _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )