[Zope-dev] moving the zope.app.* packages out of the ZTK: towards a plan

[Fred Drake]

On Tue, Dec 29, 2009 at 4:19 PM, Martijn Faassen <faassen at 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)

+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