Re: [Zope-dev] removing zope.app from the ZTK
I agree with everything except: On Tue, Dec 29, 2009 at 23:30, Martijn Faassen faas...@startifact.com wrote: Goal 2: We want users to use the ZTK instead of the Zope 3.4 KGS. I don't agree with this statement. What we want is that the Zope 3 KGS becomes based on the ZTK KGS. After that happens, people might realize they can move from Zope 3 KGS to ZTK KGS, but that's up to them. We don't want anything there. :) It depends on what they do with Zope 3. Fact 6: We were maintaining such a KGS within the ZTK. I dont' think you are. The ZTK KGS as it is today is not a replacement for the Zope 3 KGS, and never was, and never was intended as such. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] removing zope.app from the ZTK
Lennart Regebro wrote: I agree with everything except: On Tue, Dec 29, 2009 at 23:30, Martijn Faassen faas...@startifact.com wrote: Goal 2: We want users to use the ZTK instead of the Zope 3.4 KGS. I don't agree with this statement. What we want is that the Zope 3 KGS becomes based on the ZTK KGS. After that happens, people might realize they can move from Zope 3 KGS to ZTK KGS, but that's up to them. We don't want anything there. :) It depends on what they do with Zope 3. Yes, a Zope 3 KGS will have to be a superset of the ZTK KGS. If we want to retain that name at all. But there will also have to be a transitional KGS for Zope 3, that contains things that we have deprecated and can be replaced (unless the ZMI is in use) with ZTK counterparts, such as zope.app.container. This one is needed so that people can update their imports. Fact 6: We were maintaining such a KGS within the ZTK. I dont' think you are. The ZTK KGS as it is today is not a replacement for the Zope 3 KGS, and never was, and never was intended as such. Effectively we were maintaining a large part of such a KGS within the ZTK. Perhaps not everything, but much that was the old Zope 3 was in there. This was the only version list which we as a community were maintaining of those packages. I agree that the ZTK never was intended to fully replace Zope 3 so things had to change. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] removing zope.app from the ZTK
On 12/29/09 16:25 , Martijn Faassen wrote: Earlier this year we decided to refocus our efforts on the ZTK, a leaner, meaner Zope 3 with a different focus, which has code that we really use, no UI, and with cleaner dependencies. I feel a disconnect here. As I see it the ZTK is not a 'leaner, meaner Zope 3'. Zope 3 is a modular application framework, while the ZTK is a small framework that can be used to build applications or applications frameworks. ZTK has no history since it never existed before (and still is only vapourware since it has no releases nor a release manager), so it does not have any backwards compatibility to worry about. It seems that you want to have a 'ZTK+' which aims to be backwards compatible with Zope 3 but is somehow not Zope 3 itself. That is something that not everybody appears to be interested in judging by the lack of progress on Zope 3 itself, but if you want to pursue that I do not see any reason for you not to do that. But it should separate from the ZTK. Wichert. ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] removing zope.app from the ZTK
On 12/29/09 16:39 , Wichert Akkerman wrote: On 12/29/09 16:25 , Martijn Faassen wrote: Earlier this year we decided to refocus our efforts on the ZTK, a leaner, meaner Zope 3 with a different focus, which has code that we really use, no UI, and with cleaner dependencies. I feel a disconnect here. As I see it the ZTK is not a 'leaner, meaner Zope 3'. Zope 3 is a modular application framework, while the ZTK is a small framework that can be used to build applications or applications frameworks. That should have said 'Zope 3 is a modular application'. Wichert. ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] removing zope.app from the ZTK
Wichert Akkerman wrote: On 12/29/09 16:25 , Martijn Faassen wrote: Earlier this year we decided to refocus our efforts on the ZTK, a leaner, meaner Zope 3 with a different focus, which has code that we really use, no UI, and with cleaner dependencies. I feel a disconnect here. As I see it the ZTK is not a 'leaner, meaner Zope 3'. Zope 3 is a modular application framework, while the ZTK is a small framework that can be used to build applications or applications frameworks. ZTK has no history since it never existed before (and still is only vapourware since it has no releases nor a release manager), so it does not have any backwards compatibility to worry about. The sense of irony of you feeling a disconnect is rather strong here. I was the one who proposed the ZTK in the first place, remember? It seems that you want to have a 'ZTK+' which aims to be backwards compatible with Zope 3 but is somehow not Zope 3 itself. That is something that not everybody appears to be interested in judging by the lack of progress on Zope 3 itself, but if you want to pursue that I do not see any reason for you not to do that. But it should separate from the ZTK. I'm glad the message of what the ZTK is that I tried to spread so hard has arrived so well. The ZTK wants to reduce responsibilities. One of the responsibilities you gain when you want to reduce responsibilities is to do this responsibly. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] removing zope.app from the ZTK
On Tue, Dec 29, 2009 at 10:39 AM, Wichert Akkerman wich...@wiggy.net wrote: It seems that you want to have a 'ZTK+' which aims to be backwards compatible with Zope 3 but is somehow not Zope 3 itself. That is something that not everybody appears to be interested in judging by the lack of progress on Zope 3 itself, but if you want to pursue that I do not see any reason for you not to do that. But it should separate from the ZTK. Agreed; the lean mean ZTK is more interesting than this ZTK + zope.app construct. Creating a second known-good-set construct based on the ZTK and adding the selected zope.app package sounds like a straightforward task. It should be able to reuse the testing policies with little or no change. I agree with Martijn's desire for caution, however. This split should be done, but this is a split, not a simple removal of the zope.app packages without setting up this ZTK+ construct. -Fred -- 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 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 )
Re: [Zope-dev] removing zope.app from the ZTK
On 12/29/09 17:00 , Martijn Faassen wrote: Wichert Akkerman wrote: On 12/29/09 16:25 , Martijn Faassen wrote: Earlier this year we decided to refocus our efforts on the ZTK, a leaner, meaner Zope 3 with a different focus, which has code that we really use, no UI, and with cleaner dependencies. I feel a disconnect here. As I see it the ZTK is not a 'leaner, meaner Zope 3'. Zope 3 is a modular application framework, while the ZTK is a small framework that can be used to build applications or applications frameworks. ZTK has no history since it never existed before (and still is only vapourware since it has no releases nor a release manager), so it does not have any backwards compatibility to worry about. The sense of irony of you feeling a disconnect is rather strong here. I was the one who proposed the ZTK in the first place, remember? It seems that you want to have a 'ZTK+' which aims to be backwards compatible with Zope 3 but is somehow not Zope 3 itself. That is something that not everybody appears to be interested in judging by the lack of progress on Zope 3 itself, but if you want to pursue that I do not see any reason for you not to do that. But it should separate from the ZTK. I'm glad the message of what the ZTK is that I tried to spread so hard has arrived so well. The ZTK wants to reduce responsibilities. One of the responsibilities you gain when you want to reduce responsibilities is to do this responsibly. You are ignoring my point though: why should the ZTK have to be burdened with trying to be backwards compatible with something that it never was? Why are you insisting on putting Zope3 in it? Wichert. ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] removing zope.app from the ZTK
I don't think the ZTK as defined by the historical constraints under discussion here has much attraction for a large number of folks who are otherwise willing to put effort into maintaining Zope packages. For these folks, any reduction in number of dependencies and test maintenance is a net win, because they just don't use the stuff they throw out, and they don't have any Grok or legacy Zope3 apps in production to maintain that uses this stuff either. So maybe these folks should come up with their own KGS for whatever they need as a subset of the ZTK. In particular, maybe Zope2 should just be based on this subset. Martijn Faassen wrote: Wichert Akkerman wrote: On 12/29/09 16:25 , Martijn Faassen wrote: Earlier this year we decided to refocus our efforts on the ZTK, a leaner, meaner Zope 3 with a different focus, which has code that we really use, no UI, and with cleaner dependencies. I feel a disconnect here. As I see it the ZTK is not a 'leaner, meaner Zope 3'. Zope 3 is a modular application framework, while the ZTK is a small framework that can be used to build applications or applications frameworks. ZTK has no history since it never existed before (and still is only vapourware since it has no releases nor a release manager), so it does not have any backwards compatibility to worry about. The sense of irony of you feeling a disconnect is rather strong here. I was the one who proposed the ZTK in the first place, remember? It seems that you want to have a 'ZTK+' which aims to be backwards compatible with Zope 3 but is somehow not Zope 3 itself. That is something that not everybody appears to be interested in judging by the lack of progress on Zope 3 itself, but if you want to pursue that I do not see any reason for you not to do that. But it should separate from the ZTK. I'm glad the message of what the ZTK is that I tried to spread so hard has arrived so well. The ZTK wants to reduce responsibilities. One of the responsibilities you gain when you want to reduce responsibilities is to do this responsibly. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org 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 ) ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] removing zope.app from the ZTK
Wichert Akkerman wrote: [snip] You are ignoring my point though: why should the ZTK have to be burdened with trying to be backwards compatible with something that it never was? Why are you insisting on putting Zope3 in it? We should not remove it until we have a good way to upgrade people away from it. And let's please not turn this around: I'm not putting anything *in*. Something was *removed*. Let's remove it responsibly. Not just disclaim responsibility and drop it all. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] removing zope.app from the ZTK
Chris McDonough wrote: I don't think the ZTK as defined by the historical constraints under discussion here has much attraction for a large number of folks who are otherwise willing to put effort into maintaining Zope packages. For these folks, any reduction in number of dependencies and test maintenance is a net win, because they just don't use the stuff they throw out, and they don't have any Grok or legacy Zope3 apps in production to maintain that uses this stuff either. So maybe these folks should come up with their own KGS for whatever they need as a subset of the ZTK. In particular, maybe Zope2 should just be based on this subset. I think the ZTK should be a smaller thing, but we need to find what that smaller thing is first. I agree with the general idea underlying this move, just not the way it was done, disclaiming responsibility. I'm quite sure that most of the zope.app.* packages that were dropped are just not very useful anymore. But we should drop them responsibly. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] removing zope.app from the ZTK
On Tue, Dec 29, 2009 at 9:54 PM, Martijn Faassen faas...@startifact.com wrote: And let's please not turn this around: I'm not putting anything *in*. Something was *removed*. Let's remove it responsibly. Not just disclaim responsibility and drop it all. So far I defined the ZTK based on what we wrote on http://docs.zope.org/zopetoolkit/about/coreextra.html. I never considered those zope.app packages to be part of the ZTK. For me that was only a technical implementation detail on how to actually get to something that fullfils those criteria about core packages. But it seems our understanding is different and you want the responsibility of moving Zope 3 users over to the ZTK to be the responsibility of the ZTK. I don't agree with that, but that's my problem :) To be able to make more actual progress I moved Zope2 off the toolkit for now and we'll continue on our own. If at some point the ZTK offers a package set, that is actually anywhere close to what Zope2 uses, we can consider using it again. From my Zope2/Plone perspective I'm just not interested at all in any zope.app code anymore. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] removing zope.app from the ZTK
Fred Drake wrote: On Tue, Dec 29, 2009 at 10:39 AM, Wichert Akkerman wich...@wiggy.net wrote: It seems that you want to have a 'ZTK+' which aims to be backwards compatible with Zope 3 but is somehow not Zope 3 itself. That is something that not everybody appears to be interested in judging by the lack of progress on Zope 3 itself, but if you want to pursue that I do not see any reason for you not to do that. But it should separate from the ZTK. Agreed; the lean mean ZTK is more interesting than this ZTK + zope.app construct. Heh. I agree too. :) Creating a second known-good-set construct based on the ZTK and adding the selected zope.app package sounds like a straightforward task. It should be able to reuse the testing policies with little or no change. Agreed. We should find some form of status for the 'zope.app.*' packages that makes sense. These packages are already largely deprecated. Many of them are slated for deep freeze maintenance. We can talk about removing such packages from it, or even putting the whole thing into deep freeze maintenance. But right now we need to provide some guidance for how people can move away from these packages in a sane manner. And we should make sure we continue to test the zope.app.* packages when we make ZTK changes, for the time being. Let's work out a plan and a timeline. I agree with Martijn's desire for caution, however. This split should be done, but this is a split, not a simple removal of the zope.app packages without setting up this ZTK+ construct. Yes. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] removing zope.app from the ZTK
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wichert Akkerman wrote: On 12/29/09 16:25 , Martijn Faassen wrote: Earlier this year we decided to refocus our efforts on the ZTK, a leaner, meaner Zope 3 with a different focus, which has code that we really use, no UI, and with cleaner dependencies. I feel a disconnect here. As I see it the ZTK is not a 'leaner, meaner Zope 3'. Zope 3 is a modular application framework, while the ZTK is a small framework that can be used to build applications or applications frameworks. ZTK has no history since it never existed before (and still is only vapourware since it has no releases nor a release manager), so it does not have any backwards compatibility to worry about. It seems that you want to have a 'ZTK+' which aims to be backwards compatible with Zope 3 but is somehow not Zope 3 itself. That is something that not everybody appears to be interested in judging by the lack of progress on Zope 3 itself, but if you want to pursue that I do not see any reason for you not to do that. But it should separate from the ZTK. +1. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAks6cmsACgkQ+gerLs4ltQ403QCgsxsE6Ug9ucN3b+S2EQCQS0GB XesAoI12dh6pdKXuSc1zhLj7HVRxJwOe =mDQ+ -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] removing zope.app from the ZTK
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Wichert Akkerman wrote: [snip] You are ignoring my point though: why should the ZTK have to be burdened with trying to be backwards compatible with something that it never was? Why are you insisting on putting Zope3 in it? We should not remove it until we have a good way to upgrade people away from it. Who is upgrading? There are not historical users of the ZTK, only users of package sets with greater or lesser intersections with the ZTK. And let's please not turn this around: I'm not putting anything *in*. Something was *removed*. Let's remove it responsibly. Not just disclaim responsibility and drop it all. You are acting like we have code in the wild which needs to upgrade from some released version of the ZTK to a newer one, and which will thereby break. There is *no* released version: we can't possibly break anybody. People who want to consume the yet-to-be-released ZTK are going to need to make choices about how they include various pacakges which aren't part of it; there is nothing surprising about that at all. You seem to be worried that the removed packages will bitrot because they aren't part of the ZTK: going forward, that may in fact be so, but *only if they aren't being used by people who also track the ZTK*, in which case their removal has harmed no one. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAks6c4gACgkQ+gerLs4ltQ4z6wCffuFNJ0a6aonyHbQUCvntT9hX sWkAnjcTC4enCKp8xkMX/xfZlZtKvK7F =fNFn -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] removing zope.app from the ZTK
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Chris McDonough wrote: I don't think the ZTK as defined by the historical constraints under discussion here has much attraction for a large number of folks who are otherwise willing to put effort into maintaining Zope packages. For these folks, any reduction in number of dependencies and test maintenance is a net win, because they just don't use the stuff they throw out, and they don't have any Grok or legacy Zope3 apps in production to maintain that uses this stuff either. So maybe these folks should come up with their own KGS for whatever they need as a subset of the ZTK. In particular, maybe Zope2 should just be based on this subset. I think the ZTK should be a smaller thing, but we need to find what that smaller thing is first. I agree with the general idea underlying this move, just not the way it was done, disclaiming responsibility. I'm quite sure that most of the zope.app.* packages that were dropped are just not very useful anymore. But we should drop them responsibly. The maintainer who dropped them also went to a great deal of trouble to ensure that the dependencies were fixed, and that what remains is a coherent and usable set of the packages which used to be Zope3. Because of his work, and that of others, the Zope2 trunk can now run against the zope.app-free ZTK he created. You need to identify whose ox is being gored here by dropping those packages: I don't see anybody but you arguing for their inclusion. In particular, I don't see anybody who knows *which* zope.app packages they need, and has a credible argument for why those pacakges should be maintained within the ZTK, rather than by the folks who actually use them. If the ZTK is to be held hostage to a (nonsensical) BBB for nameless users, I would be in favor of just copying Hanno's version of the ZTK config into the Zope2 tree and have Zope2 ignore the ZTK per-se. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAks6dTgACgkQ+gerLs4ltQ4KIQCcDjWOMCw1clCGbv03CxEflkRv e5sAn3HLimvx7WbWEo7hujnzItV1q5XI =z8P+ -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] removing zope.app from the ZTK
On Tue, Dec 29, 2009 at 4:04 PM, Martijn Faassen faas...@startifact.com wrote: But right now we need to provide some guidance for how people can move away from these packages in a sane manner. And we should make sure we continue to test the zope.app.* packages when we make ZTK changes, for the time being. Let's work out a plan and a timeline. I think we disagree as to the scale of what's needed still. I'd be happy to see a copy of the ZTK tree get made to some recognizable name (ZATK, for Zope App Toolkit, would suffice), let Hanno commit his removal of the zope.app packages from the ZTK, and then make the ZATK refer to that version of the ZTK instead of including it directly. The only timeline that's needed is the order of the commits. If there's anyone who wants to maintain the new bastard-stepchild, they're free to step forward. There's no obligation on the part of the ZTK maintainers to do that, nor should there be. That's the whole point. -Fred -- 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 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 )
Re: [Zope-dev] removing zope.app from the ZTK
Hanno Schlichting wrote: On Tue, Dec 29, 2009 at 9:54 PM, Martijn Faassen faas...@startifact.com wrote: And let's please not turn this around: I'm not putting anything *in*. Something was *removed*. Let's remove it responsibly. Not just disclaim responsibility and drop it all. So far I defined the ZTK based on what we wrote on http://docs.zope.org/zopetoolkit/about/coreextra.html. I never considered those zope.app packages to be part of the ZTK. For me that was only a technical implementation detail on how to actually get to something that fullfils those criteria about core packages. That document should've helped clue you in about this too: The Zope Toolkit Steering Group is the final arbiter of which libraries are in Zope Toolkit or not. The idea was not to have unilateral decisions about this but to have some discussion first. I think dropping lots of libraries counts as something we need to talk about before it happens. Again, I'm fine with the *goal* of making the ZTK those packages, but we can't just leave the rest behind. But it seems our understanding is different and you want the responsibility of moving Zope 3 users over to the ZTK to be the responsibility of the ZTK. I don't agree with that, but that's my problem :) The ZTK cannot be an excuse to just drop support for a large part of the existing users of the ZTK. It's a *means* to do so. To be able to make more actual progress I moved Zope2 off the toolkit for now and we'll continue on our own. If at some point the ZTK offers a package set, that is actually anywhere close to what Zope2 uses, we can consider using it again. From my Zope2/Plone perspective I'm just not interested at all in any zope.app code anymore. The irony is that almost nobody is, including myself. But the situation is also that you as Zope 2 developers have a plan to support users that do still depend on zope.app code. Why don't you throw that plan into the wider group of people here? We have a shared problem of backwards compatibility, right? Perhaps less for Zope 2 than for other Zope Toolkit using systems, as you never used the UI or the content types. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] removing zope.app from the ZTK
Hi there, Tres Seaver wrote: [snip] Who is upgrading? There are not historical users of the ZTK, only users of package sets with greater or lesser intersections with the ZTK. [snip] You are acting like we have code in the wild which needs to upgrade from some released version of the ZTK to a newer one, and which will thereby break. You are acting like the ZTK has no history. The ZTK cannot be an excuse for our community to drop responsibilities. It can and should be a means to do so, but that takes more action than what happened here. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] removing zope.app from the ZTK
Fred Drake wrote: On Tue, Dec 29, 2009 at 4:04 PM, Martijn Faassen faas...@startifact.com wrote: But right now we need to provide some guidance for how people can move away from these packages in a sane manner. And we should make sure we continue to test the zope.app.* packages when we make ZTK changes, for the time being. Let's work out a plan and a timeline. I think we disagree as to the scale of what's needed still. I'm looking at this from the perspective of the discontinuity we will introduce for existing users of the libraries that are now in the Zope Toolkit but were formerly presented as Zope 3, and the guidance we offer for people to move onto the ZTK. When we release ZTK 1.0 we need to have some story for this. For this we need to have some level of commitment (as a community, and I think also a transition obligation of the ZTK maintainers) to maintain zopeapp as a backwards compatibility KGS for a period of time. We need to offer people and projects using the ZTK some guidance as to how to shift to the new way recommend and maintain (the ZTK). In part this can be done on a per-project basis, such as for Zope 2 and Grok. But zopeapp is something we can maintain centrally. I'm also worried about the large amount of Zope 3 code that's out there, which doesn't seem to have anyone watching out for it, possibly as people figured that'd be us, who are dropping that responsibility. [snip] If there's anyone who wants to maintain the new bastard-stepchild, they're free to step forward. There's no obligation on the part of the ZTK maintainers to do that, nor should there be. That's the whole point. On the longer term there shouldn't be any more obligation for the ZTK maintainers than to anyone else. That isn't *no* obligation, just like the Python developers feel they have some obligation not to break Python software even though they do not maintain this software. In the immediate future I think the ZTK maintainers would do well not to forget about the historical background and compatibility constraints of the ZTK. But yes, that's the point of splitting it up, indeed. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] removing zope.app from the ZTK
On Tue, Dec 29, 2009 at 23:11, Martijn Faassen faas...@startifact.com wrote: I'm looking at this from the perspective of the discontinuity we will introduce for existing users of the libraries that are now in the Zope Toolkit but were formerly presented as Zope 3, and the guidance we offer for people to move onto the ZTK. When we release ZTK 1.0 we need to have some story for this. If Zope 3 people want to move to ZTK, they a Zope 3.5 that is based on the ZTK. It's going to be very hard otherwise... ZTK is, as mentioned, not a successor to Zope 3 in any way. For this we need to have some level of commitment (as a community, and I think also a transition obligation of the ZTK maintainers) to maintain zopeapp as a backwards compatibility KGS for a period of time. What difference would there be between a zopeapp KGS and a Zope3 KGS? -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] removing zope.app from the ZTK
Hey, Tres Seaver wrote: [snip] You need to identify whose ox is being gored here by dropping those packages: I don't see anybody but you arguing for their inclusion. In particular, I don't see anybody who knows *which* zope.app packages they need, and has a credible argument for why those pacakges should be maintained within the ZTK, rather than by the folks who actually use them. That's indeed one of the problems. Fact 1: We have users that use zope.app packages. Fact 2: We suspect many of those uses are shallow and can be shifted over to non zope.app packages. Fact 3: We don't have good maintainers for most zope.app packages. Goal 1: We don't want to maintain most zope.app packages. Goal 2: We want users to use the ZTK instead of the Zope 3.4 KGS. Goal 3: We as a community have a certain ethic of supplying backwards compatibility. Fact 4: A user can more easily shift a codebase to the ZTK if we make it easy for them with a KGS. Fact 5: A ZTK-based KGS that is a smooth upgrade from the Zope 3.4 KGS helps such users to create a working environment based on the ZTK. Goal 4: We don't want to create a large discontinuity for people using existing Zope 3 applications, Grok applications or Zope 2 applications. Goal 5: We want to maintain a KGS that helps people upgrade. Goal 6: We want to maintain such a KGS collectively if we can. Fact 6: We were maintaining such a KGS within the ZTK. Goal 7: We need a way to stop maintaining such a KGS within the ZTK. Goal 8: We need a way to stop maintaining such a zopeapp KGS altogether (unless individuals step up that want to do so) The following step was taken to accomplish goal 7 and 8. Action 1: we removed the packages we don't want to maintain from the ZTK. That accomplished goal 7 and 8, but conflicts with goal 6, 5, 3 and 2. Action 2: we move the packages we don't want to maintain from the ZTK into zopeapp. .. fulfills goal 7, and doesn't conflict with goal 6, 5, 3 and 2. It doesn't fulfill goal 8 yet, but it will help us, as a community get there, by isolating the problem. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] removing zope.app from the ZTK
Lennart Regebro wrote: [snip] What difference would there be between a zopeapp KGS and a Zope3 KGS? Not much. More sharing between Grok, Zope 3 and Zope 2? Explicitly aimed at supporting backwards compatibility and upgrade path only? We've been maintaining something close to a zopeapp KGS within the ZTK until very recently. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] removing zope.app from the ZTK
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Hanno Schlichting wrote: On Tue, Dec 29, 2009 at 9:54 PM, Martijn Faassen faas...@startifact.com wrote: And let's please not turn this around: I'm not putting anything *in*. Something was *removed*. Let's remove it responsibly. Not just disclaim responsibility and drop it all. So far I defined the ZTK based on what we wrote on http://docs.zope.org/zopetoolkit/about/coreextra.html. I never considered those zope.app packages to be part of the ZTK. For me that was only a technical implementation detail on how to actually get to something that fullfils those criteria about core packages. That document should've helped clue you in about this too: The Zope Toolkit Steering Group is the final arbiter of which libraries are in Zope Toolkit or not. The idea was not to have unilateral decisions about this but to have some discussion first. I think dropping lots of libraries counts as something we need to talk about before it happens. Again, I'm fine with the *goal* of making the ZTK those packages, but we can't just leave the rest behind. But it seems our understanding is different and you want the responsibility of moving Zope 3 users over to the ZTK to be the responsibility of the ZTK. I don't agree with that, but that's my problem :) The ZTK cannot be an excuse to just drop support for a large part of the existing users of the ZTK. It's a *means* to do so. What existing users does the ZTK have? I count exactly *one* user, the Zope2 trunk (until Hanno backed it out). Everybody else is using some set of packages with a more-or-less sizable intersection with the ZTK, but with no explicity dependency on the ZTK manifest at all. To be able to make more actual progress I moved Zope2 off the toolkit for now and we'll continue on our own. If at some point the ZTK offers a package set, that is actually anywhere close to what Zope2 uses, we can consider using it again. From my Zope2/Plone perspective I'm just not interested at all in any zope.app code anymore. The irony is that almost nobody is, including myself. That isn't ironic, because we were all fully aware of it: it does make your point absurd, however. But the situation is also that you as Zope 2 developers have a plan to support users that do still depend on zope.app code. Why don't you throw that plan into the wider group of people here? Because it is not relevant? Zope2 does *not* intend to provide convenience dependencies for BBB purposes, nor does Zope2 have any plans for testing the no-longer-included packages in conjunction with those which are included: apps / frameworks which want to move to Zope 2.13 will need to pull in those dependencies themselves, and do any appropriate maintenance / testing of them. If that strategy works for the ZTK, then there is no reason to revert it to include zope.app.*. We have a shared problem of backwards compatibility, right? Wrong. The strategy used for Zope2 was to eradicate use of those packages, and to ship 2.13 in a configuration which doesn't include them in any fashion. Zope2 apps or frameworks which need zope.app pacakges must declare those dependencies explicitly, and assume the burden of maintaining / pinning appropriate / compatible versions. Perhaps less for Zope 2 than for other Zope Toolkit using systems, as you never used the UI or the content types. You keep asserting a backward compatibility problem, but haven't defended it with any evidence. Be specific: who is hurt by the removal of packages from the ZTK? - - You can't claim that Grok users are so hurt: they have their own KGS, and have not yet made a committment to use the ZTK, where commitment means doing the work required to define their superset of packages as a delta to the ZTK. Instead, the Grok versions.cfg file contains a *copy* of some version of the ZTK, including a bunch of zope.app packages. It isn't even clear which of the zope.app packages are genuinely needed by Grok, as opposed to being copied in wholesale. Grok's existing test infrastructure drives of that versions.cfg file, and is so insulated from any changes to the ZTK. - - The Zope3 crowd has again gone mostly silent, but their KGS setup doesn't depend on the ZTK in anyway. The big majority of the zope.app packages are *only* interesting to this group, and will likely only be maintained by this group. - - Potential future users of the zope.app packages? Removing them from the ZTK is actually beneficial to those users, because it signals their relatively narrow focus and usefulness, as well as removing any implied proomise that they are being actively maintained by the wider Zope communtiy. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Design
Re: [Zope-dev] removing zope.app from the ZTK
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fred Drake wrote: On Tue, Dec 29, 2009 at 4:04 PM, Martijn Faassen faas...@startifact.com wrote: But right now we need to provide some guidance for how people can move away from these packages in a sane manner. And we should make sure we continue to test the zope.app.* packages when we make ZTK changes, for the time being. Let's work out a plan and a timeline. I think we disagree as to the scale of what's needed still. I'd be happy to see a copy of the ZTK tree get made to some recognizable name (ZATK, for Zope App Toolkit, would suffice), let Hanno commit his removal of the zope.app packages from the ZTK, and then make the ZATK refer to that version of the ZTK instead of including it directly. The only timeline that's needed is the order of the commits. If there's anyone who wants to maintain the new bastard-stepchild, they're free to step forward. There's no obligation on the part of the ZTK maintainers to do that, nor should there be. That's the whole point. +1. My feelinge exactly. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAks6hrkACgkQ+gerLs4ltQ6CSQCgtrMQVOADLC9vXX8LKK3gN+mi n94AoLlMSpZsuXRom3G2FOapPHkxw0AC =UMmW -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] removing zope.app from the ZTK
Tres Seaver wrote: Martijn Faassen wrote: [snip] The ZTK cannot be an excuse to just drop support for a large part of the existing users of the ZTK. It's a *means* to do so. What existing users does the ZTK have? I'll rewrite that: The ZTK cannot be an excuse to just drop support for a large part of the existing users of packages that are in the ZTK, namely the users of Zope 3.4. It's a means to do so. We have three perspectives: * the ZTK is new, therefore the ZTK doesn't need to care about Zope 3 at all. * the ZTK is a renamed, refocused Zope 3, therefore the ZTK needs to care about Zope 3. * both: the ZTK is a way for us to stop caring about Zope 3, given some work. I'm in the both camp. This is a transition problem. I'm arguing in favor of handling this transition properly. I count exactly *one* user, the Zope2 trunk (until Hanno backed it out). Everybody else is using some set of packages with a more-or-less sizable intersection with the ZTK, but with no explicity dependency on the ZTK manifest at all. The Grok 1.1 alphas are based on a slightly older version of the ZTK. (I see you discount this as proper use of the ZTK below) [snip] Because it is not relevant? Zope2 does *not* intend to provide convenience dependencies for BBB purposes, nor does Zope2 have any plans for testing the no-longer-included packages in conjunction with those which are included: apps / frameworks which want to move to Zope 2.13 will need to pull in those dependencies themselves, and do any appropriate maintenance / testing of them. If that strategy works for the ZTK, then there is no reason to revert it to include zope.app.*. Okay. I wonder how that's going to work out for the Zope 2 users. I think a zopeapp KGS that will help them transition existing code from Zope 2.12 to Zope 2.13 in working condition would be helpful to Zope 2 users. We have a shared problem of backwards compatibility, right? Wrong. The strategy used for Zope2 was to eradicate use of those packages, and to ship 2.13 in a configuration which doesn't include them in any fashion. Zope2 apps or frameworks which need zope.app pacakges must declare those dependencies explicitly, and assume the burden of maintaining / pinning appropriate / compatible versions. Why not maintain such a list together instead of letting everybody figure this out themselves? It's not always easy to make sure you have the right packages. We were maintaining this list together, until very recently. For instance, with Grok, we had a situation where we were using a newer version of zope.app.container by accident, thus pulling in zope.container in a Zope 3.4 situation. With Zope 2 I can see the reverse situation, where someone accidentally pins a version of zope.app.container that doesn't yet depend on the zope.container implementation. A KGS can help there., Perhaps less for Zope 2 than for other Zope Toolkit using systems, as you never used the UI or the content types. You keep asserting a backward compatibility problem, but haven't defended it with any evidence. Be specific: who is hurt by the removal of packages from the ZTK? Everybody who uses any previous KGS, once they upgrade their codebases to use the ZTK. Unless they can pull in the extended list of zope.app packages, so that they can upgrade their app without having to assemble a working list of ZTK compatible versions themselves. (and then they can go and remove the zope.app dependencies) - - You can't claim that Grok users are so hurt: they have their own KGS, and have not yet made a committment to use the ZTK, where commitment means doing the work required to define their superset of packages as a delta to the ZTK. Instead, the Grok versions.cfg file contains a *copy* of some version of the ZTK, including a bunch of zope.app packages. It isn't even clear which of the zope.app packages are genuinely needed by Grok, as opposed to being copied in wholesale. Grok's existing test infrastructure drives of that versions.cfg file, and is so insulated from any changes to the ZTK. To copy a ZTK list is just a technical decision because we cannot rely on a released version of the ZTK yet. We don't want unexpected test breakage due to changes in the ZTK. We would certainly have had some unexpected breakage this week! Copying the new list without having a zope.app list known to work would present us with a problem. Grok 1.1 is slated to use the ZTK (perhaps again by copying the ZTK list). (Grok's need to have cleaner dependencies provided a large amount of the initial momentum into the ZTK project) Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] removing zope.app from the ZTK
On Tue, Dec 29, 2009 at 6:11 PM, Martijn Faassen faas...@startifact.com wrote: * the ZTK is new, therefore the ZTK doesn't need to care about Zope 3 at all. I'm strongly in this camp. The other camps can readily be supported on top of this view of the ZTK by providing new names for higher-level toolkits and applications. Without the scope reduction on the ZTK, there's not really any motivation for it. -Fred -- 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 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 )
Re: [Zope-dev] removing zope.app from the ZTK
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: We have three perspectives: * the ZTK is new, therefore the ZTK doesn't need to care about Zope 3 at all. +1 * the ZTK is a renamed, refocused Zope 3, therefore the ZTK needs to care about Zope 3. - -1 * both: the ZTK is a way for us to stop caring about Zope 3, given some work. - -1 I think a zopeapp KGS that will help them transition existing code from Zope 2.12 to Zope 2.13 in working condition would be helpful to Zope 2 users. I do not believe there is any meaningful group of people who would be catastrophically affected by not having this transition become part of the ZTK's responsibilities. You keep asserting a backward compatibility problem, but haven't defended it with any evidence. Be specific: who is hurt by the removal of packages from the ZTK? Everybody who uses any previous KGS, once they upgrade their codebases to use the ZTK. Unless they can pull in the extended list of zope.app packages, so that they can upgrade their app without having to assemble a working list of ZTK compatible versions themselves. (and then they can go and remove the zope.app dependencies) Again, I doubt there is any meaningful number of people falling into this group. jens P.S.: I'm watching on the sidelines because I consider myself much more of a simple Zope 2 user than someone who has valid input for the ZTK per se. I just don't grok (pun intended) any of these assertions that the ZTK has any responsibility for providing a stepping stone for zope.app.*-package users. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAks6kAAACgkQRAx5nvEhZLLo9ACfWKWew8mTwkW5DFRx4E9UCwQJ nPQAoI6s1s5D3IiOC3bHSGJibNDwQUUs =ARZn -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] removing zope.app from the ZTK
On Wed, Dec 30, 2009 at 12:11 AM, Martijn Faassen faas...@startifact.com wrote: I think a zopeapp KGS that will help them transition existing code from Zope 2.12 to Zope 2.13 in working condition would be helpful to Zope 2 users. Not really. Zope 2.12 is exactly that transitionary release defining a KGS for everything that was included in Zope 2.11 (~3.4.1). We already have our version of the zopeapp KGS with that. Everyone else is free to reuse this KGS, but so far nobody was interested in it. It reflects the status of zope.*/zope.app.* a couple months back. With Plone 4 based on this KGS, we are going to maintain it for the next couple of years. It's not completely zope.app-free but close enough to make the jump to 2.13 trivial for Zope2 projects. Why not maintain such a list together instead of letting everybody figure this out themselves? It's not always easy to make sure you have the right packages. We were maintaining this list together, until very recently. The list we were maintaining together, was what I thought to be the KGS *after* the transition period. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] removing zope.app from the ZTK
Hanno Schlichting wrote: On Wed, Dec 30, 2009 at 12:11 AM, Martijn Faassen faas...@startifact.com wrote: I think a zopeapp KGS that will help them transition existing code from Zope 2.12 to Zope 2.13 in working condition would be helpful to Zope 2 users. Not really. Zope 2.12 is exactly that transitionary release defining a KGS for everything that was included in Zope 2.11 (~3.4.1). Ah, I didn't realize Zope 2.12 was already based on an earlier version of the ZTK. Then I guess I mean zopeapp might help people transitioning from 2.11 to Zope 2.13. I don't know how many people are making that transition. We already have our version of the zopeapp KGS with that. Everyone else is free to reuse this KGS, but so far nobody was interested in it. I missed where you offered this list for more general reuse. If I'd known about it might have been useful for us working for Grok, and as a basis of zopeapp. I'm interested the current zopeapp to support the Grok transition and to help people transition Zope 3 apps. I didn't realize Zope 2 was already that far along having released earlier ZTK versions. It reflects the status of zope.*/zope.app.* a couple months back. With Plone 4 based on this KGS, we are going to maintain it for the next couple of years. It's not completely zope.app-free but close enough to make the jump to 2.13 trivial for Zope2 projects. Why not maintain such a list together instead of letting everybody figure this out themselves? It's not always easy to make sure you have the right packages. We were maintaining this list together, until very recently. The list we were maintaining together, was what I thought to be the KGS *after* the transition period. I'm not sure what you mean here. Anyway, there are now two lists in my mind: the ZTK list (yours), and the zopeapp list. Both are useful to share, though the ZTK is obviously the main goal. I was proposing zopeapp is useful for Zope 2 developers, but apparently not much as the use of the ZTK is out of sync. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] removing zope.app from the ZTK
On Wed, Dec 30, 2009 at 12:55 AM, Martijn Faassen faas...@startifact.com wrote: Hanno Schlichting wrote: Not really. Zope 2.12 is exactly that transitionary release defining a KGS for everything that was included in Zope 2.11 (~3.4.1). Ah, I didn't realize Zope 2.12 was already based on an earlier version of the ZTK. Then I guess I mean zopeapp might help people transitioning from 2.11 to Zope 2.13. I don't know how many people are making that transition. Not many. Zope 2.11 hasn't been in much use. Arguably the largest group of people are doing this through Plone. There the story is different again, as the lastest stable Plone release (3.3) is based on Zope 2.10 which included Zope 3.3.2. Plone 4, which should see a beta release any day now, is based on Zope 2.12 (including ZTK 0.5). We'll see a number of Plone 4.x releases, which will most likely stick to Zope 2.12. Only Plone 5 (which I happen to be release manager of) will use a new Zope 2.13. Since Plone is basically driving the Zope 2 release schedule these days, we'll likely not see a new major Zope 2 release until Plone 5 alphas are getting ready. So the two main upgrade paths we have are Zope 3.3.2 to ZTK 0.5. And then at some point in maybe 12 to 18 months a ZTK 0.5 to ZTK x.y upgrade. This also means that an actual ZTK release, that is done anywhere before late 2010 is pretty much not usable for Zope 2. If the difference between our ZTK 0.5 release and the final version gets too large and breaks backwards compatibility, we have another problem. Grok's release schedule obviously looks very different from this. And I have no idea what the schedules of any other potential users of the ZTK might look like. Agreeing on the scope and timeframe of the or many ZTK releases is going to be quite interesting in itself. I missed where you offered this list for more general reuse. If I'd known about it might have been useful for us working for Grok, and as a basis of zopeapp. I'm interested the current zopeapp to support the Grok transition and to help people transition Zope 3 apps. I didn't realize Zope 2 was already that far along having released earlier ZTK versions. Well, we did a freeze of our ZTK KGS with our Zope 2.12 beta 2 release. This happened end of May 2009. At that point Grok was a long way from having an actual 1.0 release, which only happened much later facilitated by the Neanderthal sprint in September. This whole topic wasn't really on your radar at that point. But Zope2 and Plone couldn't wait for an indefinite time, hoping that someday the ZTK would actually be ready. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] removing zope.app from the ZTK
Hanno Schlichting wrote: [snip explanation of current Zope 2 and Plone plans, thanks] So the two main upgrade paths we have are Zope 3.3.2 to ZTK 0.5. And then at some point in maybe 12 to 18 months a ZTK 0.5 to ZTK x.y upgrade. This also means that an actual ZTK release, that is done anywhere before late 2010 is pretty much not usable for Zope 2. If the difference between our ZTK 0.5 release and the final version gets too large and breaks backwards compatibility, we have another problem. ZTK 0.5 still contains zope.app.* packages, correct? Assuming ZTK x.y won't have zope.app packages, this means that those upgrading to Zope 2.13 might be helped by a list of working versions of those zope.app.* packages (such as the one in zopeapp), or am I wrong? Of course I imagine this list is quite short in your case, as you were already on ZTK 0.5. Grok's release schedule obviously looks very different from this. And I have no idea what the schedules of any other potential users of the ZTK might look like. Agreeing on the scope and timeframe of the or many ZTK releases is going to be quite interesting in itself. Yes, and agreeing about what transition support we supply seems to be even more interesting. :) I missed where you offered this list for more general reuse. If I'd known about it might have been useful for us working for Grok, and as a basis of zopeapp. I'm interested the current zopeapp to support the Grok transition and to help people transition Zope 3 apps. I didn't realize Zope 2 was already that far along having released earlier ZTK versions. Well, we did a freeze of our ZTK KGS with our Zope 2.12 beta 2 release. This happened end of May 2009. At that point Grok was a long way from having an actual 1.0 release, which only happened much later facilitated by the Neanderthal sprint in September. This whole topic wasn't really on your radar at that point. Yes, it was too early for Grok. That said, the ZTK topic has been on my radar from the start, and helping to start it we were obviously thinking about upgrading Grok to it from the start. Earlier on, we had quite a big discussion about What is the ZTK where various people were arguing for starting with a short list and building it up, versus starting with the long list and whittling it down. At the time we went with the latter. One of the motivations for the long list I believe was to help people transition better. I don't recall the splitting lists idea coming up (one main, one backwards compatibility) but that was probably because it was infeasible then given the large amount of zope.app dependencies we still had. At some point the Zope 2 developers came up with that idea as you evidently did it, but the idea didn't flow back into the ZTK at the time. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] removing zope.app from the ZTK
On Wed, Dec 30, 2009 at 1:46 AM, Martijn Faassen faas...@startifact.com wrote: Assuming ZTK x.y won't have zope.app packages, this means that those upgrading to Zope 2.13 might be helped by a list of working versions of those zope.app.* packages (such as the one in zopeapp), or am I wrong? Of course I imagine this list is quite short in your case, as you were already on ZTK 0.5. The list is quite small indeed. There's: zope.app.appsetup zope.app.basicskin zope.app.debug zope.app.dependable zope.app.pagetemplate zope.app.publication zope.app.publisher zope.app.schema all of which don't matter, as those are just transitive dependencies but contain no code that was usable inside Zope 2. And then there's: zope.app.component zope.app.container zope.app.form zope.app.testing zope.app.component was mostly used to import the hooks getSite / setSite stuff. But we already have zope.site containing those and app.component is just a BBB shim. Almost nothing inside zope.app.container is actually used, as we have OFS and Products.BTreeFolder as the canonical folder implementations, in any case app.container is a BBB shim around container as well. zope.app.form has a bit of a special status, but we solved that by factoring out the entire formlib / app.form dependency into an extra distribution called five.formlib. Users of formlib can switch to that during Zope 2.12, in 2.13 we won't have to ship it anymore. And finally zope.app.testing had seen some uses for the ztapi stuff or test setup, but generally we have Testing and ZopeTestCase that provide the Zope2 specific versions of those. And well, that's it. Since most of the other code inside zope.app was never actually usable inside Zope 2, we don't have that much of a problem with it. Some other things are hidden behind ZCML constructs like the various browser registrations and Zope 2 takes care of loading the right meta.zcml's for you. Other stuff is hidden behind Five, which actually works to our advantage now ;) Earlier on, we had quite a big discussion about What is the ZTK where various people were arguing for starting with a short list and building it up, versus starting with the long list and whittling it down. At the time we went with the latter. One of the motivations for the long list I believe was to help people transition better. Yeah, I was a proponent of the start small approach :) Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
