On Tue, Dec 29, 2009 at 4:19 PM, Martijn Faassen <faas...@startifact.com> 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)
> * we pull the zope.app.* packages from the ZTK and move them into zopeapp.
> * 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)
> * 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
+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 L. Drake, Jr. <fdrake at gmail.com>
"Chaos is the score upon which reality is written." --Henry Miller
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -