Hanno Schlichting wrote:
- Look at Tres's list of packages in all three frameworks, decide on a way to drop things from the initial ZTK set and on a process for the future.
As long as things are not dropped immediately. Even though Grok 1.2 might not need foo.bar, transition support might mean it requires it still for those people who are porting over existing projects. Note also that Tres' list is not exactly accurate as it comes to Grok, as Tres assumed that information about deprecation in Grok's setup.py was actually correct. :). Please be careful with that. I think Grok's upcoming 1.2 list will be better.
- Look at and update http://docs.zope.org/zopetoolkit/about/coreextra.html for adding/removing policies, probably have a deprecated.cfg file
A deprecated.cfg would be a way to support this. Most of zopeapp.cfg could eventually go into deprecated.cfg. The tricky question is what to do those things in zopeapp.cfg which won't be deprecated any time soon. An example is zope.app.wsgi. Should it stay in zopeapp.cfg? we could rename it to zope.wsgi and move it into the ztk.cfg too. You can then argue that since Zope 2 doesn't use it, it shouldn't be in the ZTK, but there are already packages in the ZTK that aren't used by Zope 2. If we moved the four to six things out of zopeapp.cfg over into ztk.cfg (and deprecated the rest) might that be an acceptable extra burden for those who don't use these packages? Eventually of course we'd even want to dump deprecated stuff completely so that we don't need to maintain it at all anymore. We can even move that code into a subdir in SVN and put markers in pypi. You'd need a clear procedure for that too. Regards, Martijn