On Tue, Dec 29, 2009 at 4:19 PM, Martijn Faassen <[email protected]> wrote: > Let me sketch out some ideas for a plan:
Thankfully you started getting this done while I was distracted from my email by a meeting. :-) I'll send this anyway, since there's probably a few points of contention still, though I don't think they're large or difficult to work out. > * we create a new project, zopeapp, with the same structure as the > zopetoolkit (sans documentation) +1 > * we pull the zope.app.* packages from the ZTK and move them into zopeapp. +1 > * we make sure we have a way to regularly run the zopeapp tests in > conjunction with the ZTK. -1 (not the problem of the ZTK maintainers; anyone who cares can start from the machinery used for the ZTK, if they exist) > * we then move towards a release of ZTK 1.0 (see Hanno's mail for lots > of things we need to work out) +1 > * we also release zopeapp 1.0 in conjunction with it. This is just a > backwards compatibility KGSish thing. We explicitly don't strive to > document it, etc. -1 (again, not the problem for the ZTK maintainers; let's let someone who cares worry about what constitutes "1.0" or any other release) > * we announce that we strive to deprecate what's in zopeapp 1.0 and that > we expect users to shift to use ZTK packages as much as possible and > report back any difficulties they have with this. -1 (let those who care about the packages in the fledgling zopeapp decide what to do with them) > * this will help us determine whether there is still useful code left in > zopeapp that we wish to salvage into the ZTK or otherwise maintain. -1 (no need) > * this will also help us determine which packages in zopeapp are more > generally useful, and strive to isolate them from the rest of zopeapp. > zope.formlib is an example of this. Packages not in the ZTK can be considered for adoption into the ZTK based on the policies of ZTK maintenance; no need for a separate review step as part of splitting things up. > * depending on our experiences in Zope 2, Zope 3 and Grok apps we can > decide whether we can put zopeapp in the deep freeze: not maintain it > anymore. +1 that it's not a ZTK issue. There's no action for the ZTK maintainers in this. > * we then also look into shunting away the zope.app.* packages from the > top-level SVN into an "this is old stuff area" by that time. -1 (no need) > Note that we also have a long-standing idea of a "wider KGS" which > contains the ZTK plus perhaps zopeapp plus more, such as z3c.form. This > is a related exercise. Again, this isn't a ZTK issue, but a consideration for those interested in those higher-level projects. > Once we have some discussion we can hopefully flesh out this plan, put > in some dates and such, and put the plan in the Zope Toolkit documentatino. -1 (such projects should not be incorporated into the ZTK project) -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Chaos is the score upon which reality is written." --Henry Miller _______________________________________________ Zope-Dev maillist - [email protected] 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 )
