moving the zope.app.* packages out of the ZTK: towards a plan
Hi there, Let me sketch out some ideas for a plan: * 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. * 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. * 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. * 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. * 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. * 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. * 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. 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. 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. Regards, Martijn
Hey, Martijn Faassen wrote:
Let me sketch out some ideas for a plan:
* we create a new project, zopeapp, with the same structure as the zopetoolkit (sans documentation)
I've created such a project here, based on the zope.app* stuff that was in the ZTK. http://svn.zope.org/Sandbox/faassen/zopeapp/
* we pull the zope.app.* packages from the ZTK and move them into zopeapp.
That's what I just did. zopeapp currently relies on this ZTK branch: http://svn.zope.org/zopetoolkit/branches/faassen-smaller/ which is effectively Hanno's version. In retrospect I should have just gone for this right away instead of reverting stuff. We haven't had a lot of attention from a lot of people in this discussion yet, so we'll give it a few more days (it being the holiday season). I propose we aim for going back to Hanno's trunk again sometime next week, depending on how the discussion proceeds.
* we make sure we have a way to regularly run the zopeapp tests in conjunction with the ZTK.
I have a link to the faassen-smaller branch from zopeapp, so it at least can stay in sync. We need to hook this stuff in some buildbot and/or make sure someone checks it for breakage. The rest of the plan still needs dates and stuff, and documentation written. That's mostly ZTK 1.0 release planning (with some backwards compatibility provisions) Regards, Martijn
On Tue, Dec 29, 2009 at 4:19 PM, Martijn Faassen <faassen@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
Hi there, Fred Drake wrote:
On Tue, Dec 29, 2009 at 4:19 PM, Martijn Faassen <faassen@startifact.com> wrote:
Let me sketch out some ideas for a plan: [snip] * 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)
[snip]
* 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)
[snip]
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.
I agree with these -1, but only from the perspective of the future, not from the perspective of the transition we're in. These are ZTK issues only in as much as that these are issues of the users of the ZTK, just like any other users of the ZTK. The ZTK developers should not have to maintain other KGSes.
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)
This is a problem for the zope-dev community, which includes the ZTK maintainers. So however we want to make responsible, as a zope-dev community we are still responsible. I will now argue why I think this is a particular responsibility for the ZTK maintainers at this time. This is because it is a transition problem. I am assuming that the ZTK maintainers want to attract users to the ZTK. One important class of users is the existing users we have of libraries in this toolkit. In fact this is realistically speaking almost all the people on the ZTK in the near future, until we vastly improve documentation. It makes sense to help these people to transition onto the ZTK, as the ZTK without users is pointless. So I'm proposing we incorporate the zopeapp project as a project with an *explicitly limited responsibility* within the ZTK project *for a limited period of time*, during the phase of transition, to assist people to upgrade to use the ZTK within their project. After the transition phase, which we should clearly communicate, the ZTK maintainers have a responsibility to the zopeapp project in the same way as they have a responsibility to other projects that use the ZTK. So, after the transition, zopeapp will cease to be a special responsibility for the ZTK maintainers. If we really care about not making ZTK maintainers responsible for this in any way, we could instead create a special "transition" project out of this, but that seems overkill. We could also relegate it to the inactive Zope 3 development community we were trying to fix in the first place.. Regards, Martijn
participants (2)
-
Fred Drake -
Martijn Faassen