shrinking the ZTK: a proposed solution
Hi there, So here's my proposed solution for the ZTK shrinking issue: The ZTK branch 'faassen-smaller' contains Hanno's smaller ZTK. Since Zope 2 forked the ZTK in response and continued to make changes to their fork, I've tried to keep it in sync with the Zope 2 fork. I've created a new 'zopeapp' package that expands the ZTK with zope.app. packages in my sandbox. This extracts that information from the ZTK. Hopefully after we get some feedback from other steering group members (very silent indeed in the holiday period when all this happened) we can make these two projects the official one: a ZTK project and a zopeapp project. A few things I ask the ZTK maintainers: I ask the ZTK maintainers to have the same concern for the zope.app packages as for any other user of the ZTK: work to support zopeapp's compatibility with the ZTK. If the zopeapp maintainers have issues, listen to them seriously. I think everybody can agree that this is within the ZTK mandate for the time being, as zopeapp clearly exists and is being used by a significant amount of people. (I'd like to work to retire it by making it used by far less people) I also strongly encourage the ZTK maintainers to consider the situation of backwards compatibility seriously. Help people transition from their code now to the ZTK. Helping everybody migrate to the ZTK smoothly increases the value of the ZTK itself. Obviously I cannot *force* ZTK maintainers to worry about this. Instead I'm appealing to your self-interest. And of course the transition burden is shared and should not fall solely or even predominantly on the ZTK maintainers. I also think we as ZTK maintainers should better consider the concerns of other users of the ZTK. In this case, Zope 2 had less of a concern for zope.app than Grok or Zope 3. I didn't even understand this until the debate was further along. The concerns of others should be considered as well instead of simply rejected. We usually can find ways to balance the concerns of everybody. To that end concerns (or lack thereof) should be clearly communicated and be listened to. Regards, Martijn
I agree and support Martijn's strategy. There are *many* Zope 3 users who are not visible on this discussion. For example, these CMS are based on Zope 3, as you can find the word on the page. http://z3ext.net/news/z3ext-1_0_0-released/ https://makunouchi.jp/products Not only them, but more Zope 3 based systems exist which are not exposed on internet. I think ZTK community needs to think about them. In other words, Some directions should be provided to them when ZTK 1.0 gets released. Probably, many Zope 3 users are not participating community nor subscribing this mailing list. But developers who are developing *foundation* software need to consider *big* world beyond directly visible scope. I am not a programmer, but I have translated philikon's web component development book. http://www.springer.jp/978-4-431-10040-9 Takeshi Yamamoto On Jan 4, 2010, at 5:51 AM, Martijn Faassen wrote:
I think everybody can agree that this is within the ZTK mandate for the time being, as zopeapp clearly exists and is being used by a significant amount of people. (I'd like to work to retire it by making it used by far less people)
Hi,
So here's my proposed solution for the ZTK shrinking issue:
The ZTK branch 'faassen-smaller' contains Hanno's smaller ZTK. Since Zope 2 forked the ZTK in response and continued to make changes to their fork, I've tried to keep it in sync with the Zope 2 fork.
I've created a new 'zopeapp' package that expands the ZTK with zope.app. packages in my sandbox. This extracts that information from the ZTK.
Hopefully after we get some feedback from other steering group members (very silent indeed in the holiday period when all this happened) we can make these two projects the official one: a ZTK project and a zopeapp project.
+1 I think we do need to start being a bit more explicit about who these people are, though, or (I think more reasonably, at least in the short term) acknowledge that really there's one community: the Zope one; and various *audiences*. Documenting that somewhere (and possibly letting people indicate their interest in one or more audiences and one or more sub-projects, like ZTK vs. ZopeApp) would at least help us make sure that we had all points of view represented.
A few things I ask the ZTK maintainers:
I ask the ZTK maintainers to have the same concern for the zope.app packages as for any other user of the ZTK: work to support zopeapp's compatibility with the ZTK. If the zopeapp maintainers have issues, listen to them seriously. I think everybody can agree that this is within the ZTK mandate for the time being, as zopeapp clearly exists and is being used by a significant amount of people. (I'd like to work to retire it by making it used by far less people)
I also strongly encourage the ZTK maintainers to consider the situation of backwards compatibility seriously. Help people transition from their code now to the ZTK. Helping everybody migrate to the ZTK smoothly increases the value of the ZTK itself. Obviously I cannot *force* ZTK maintainers to worry about this. Instead I'm appealing to your self-interest. And of course the transition burden is shared and should not fall solely or even predominantly on the ZTK maintainers.
I also think we as ZTK maintainers should better consider the concerns of other users of the ZTK. In this case, Zope 2 had less of a concern for zope.app than Grok or Zope 3. I didn't even understand this until the debate was further along. The concerns of others should be considered as well instead of simply rejected. We usually can find ways to balance the concerns of everybody. To that end concerns (or lack thereof) should be clearly communicated and be listened to.
+1 to all of that. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martijn Faassen wrote:
Hi there,
So here's my proposed solution for the ZTK shrinking issue:
The ZTK branch 'faassen-smaller' contains Hanno's smaller ZTK. Since Zope 2 forked the ZTK in response and continued to make changes to their fork, I've tried to keep it in sync with the Zope 2 fork.
I've created a new 'zopeapp' package that expands the ZTK with zope.app. packages in my sandbox. This extracts that information from the ZTK.
Hopefully after we get some feedback from other steering group members (very silent indeed in the holiday period when all this happened) we can make these two projects the official one: a ZTK project and a zopeapp project.
A few things I ask the ZTK maintainers:
I ask the ZTK maintainers to have the same concern for the zope.app packages as for any other user of the ZTK: work to support zopeapp's compatibility with the ZTK. If the zopeapp maintainers have issues, listen to them seriously. I think everybody can agree that this is within the ZTK mandate for the time being, as zopeapp clearly exists and is being used by a significant amount of people. (I'd like to work to retire it by making it used by far less people)
You're kidding, right? Different frameworks / pacakges use sets of packages which intersect with the one you just invented and labeled 'zopeapp', but *nobody* is using that labeled set: it didn't even exist a hundred hours ago. One thing that the consumers of zope.app.* packages can do first is to contribute lists the specific sets (and pinned versions) they depend on: without such information, nobody can work to ensure that zopeapp is useful to those consumers. Yes, I'm thinking specifically of Grok here, for one: I don't think
I also strongly encourage the ZTK maintainers to consider the situation of backwards compatibility seriously. Help people transition from their code now to the ZTK. Helping everybody migrate to the ZTK smoothly increases the value of the ZTK itself.
People need to step up and ask for such help before it is even feasible to consider helping them.
Obviously I cannot *force* ZTK maintainers to worry about this. Instead I'm appealing to your self-interest. And of course the transition burden is shared and should not fall solely or even predominantly on the ZTK maintainers.
My self-interest? Not really: you are appealing to my altruism, in the fact that I care about the *broader* Zope community (broader than Zope2, Grok, Plone, or whatever. Neither of my chosen platforms (Zope2, bfg) rely any longer on any of thsoe pacakages at all, which makes my direct interest in them exactly zero. Again, once real users with non-hypothetical needs speak up, I know that the Zope developer community will help them, as it has alwasy done in the past.
I also think we as ZTK maintainers should better consider the concerns of other users of the ZTK. In this case, Zope 2 had less of a concern for zope.app than Grok or Zope 3. I didn't even understand this until the debate was further along. The concerns of others should be considered as well instead of simply rejected. We usually can find ways to balance the concerns of everybody. To that end concerns (or lack thereof) should be clearly communicated and be listened to.
For the ZTK to have any usefulness apart from "mere aggregation", it needs to have a "crisp" identity. Anything which gets pulled into it without specific, concrete need muddies that identity, and reduces the value. Pushing to keep the set as small as possible is intended to raise the quality and usefulness of the set for *all* its users: excluding packages can actually help users of the ZTK who also use the excluded packages, precisely because it makes clear the costs of using the excluded pacakges (helping maintain them, for one). Should the zopeapp set get users (e.g., Baiju's BlueBream takes off, or if another Z3-based app ports to using it), that will make supporting zopeapp's needs a reasonable request, simliar to supporting Plone via Zope2. Until people organize such a community of interest around the zopeapp set (or some other grouping), we don't have non-hypothetical reasons to consider it viable. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktCZzgACgkQ+gerLs4ltQ7skwCdGyVfRxjM+LPl0SA6l2fRo84a OjIAn1G06ze2fwjDgPxpmOO0o4MClbJa =9AHz -----END PGP SIGNATURE-----
Am Montag 04 Januar 2010 23:10:05 schrieb Tres Seaver:
Martijn Faassen wrote:
Hi there,
So here's my proposed solution for the ZTK shrinking issue: Should the zopeapp set get users (e.g., Baiju's BlueBream takes off, or if another Z3-based app ports to using it), that will make supporting zopeapp's needs a reasonable request, simliar to supporting Plone via Zope2. Until people organize such a community of interest around the zopeapp set (or some other grouping), we don't have non-hypothetical reasons to consider it viable.
To give you some personal insight: Two of my ongoing projects - which are quite big - rely on zope.app. At least, I have various imports from these modules: zope.app.authentication zope.app.security zope.app.container zope.app.component zope.app.pagetemplate zope.app.exception I'd rather not like to rewrite all that in case zope.app dies off. But I have to further state that I'm locked into Zope 3.4.0 as the support for Python 2.4 was dropped, so I can't upgrade to the current ZTK. Therefore I'm currently not that much affected by those issues, but I personally hope that BlueBream takes off as this seems to be the logical upgrade path for me in the future. Best Regards, Hermann -- hermann@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7
Hermann Himmelbauer wrote:
But I have to further state that I'm locked into Zope 3.4.0 as the support for Python 2.4 was dropped, so I can't upgrade to the current ZTK.
This is a surprise to me. I thought we still supported Python 2.4 Regards, Martijn
Am Dienstag 05 Januar 2010 11:58:38 schrieb Martijn Faassen:
Hermann Himmelbauer wrote:
But I have to further state that I'm locked into Zope 3.4.0 as the support for Python 2.4 was dropped, so I can't upgrade to the current ZTK.
This is a surprise to me. I thought we still supported Python 2.4
That's a surprise to me, too: I remember endless discussions about dropping support for Python 2.4 on this list, let me see: https://mail.zope.org/pipermail/zope-dev/2009-April/036387.html I thought the outcome was somehow that Python 2.4 support was dropped? But I'd appreciate it a lot, if I'm wrong on this! Do the tests pass with Python 2.4 for the ZTK? Best Regards, Hermann -- hermann@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7
Hermann Himmelbauer wrote:
Am Dienstag 05 Januar 2010 11:58:38 schrieb Martijn Faassen:
Hermann Himmelbauer wrote:
But I have to further state that I'm locked into Zope 3.4.0 as the support for Python 2.4 was dropped, so I can't upgrade to the current ZTK. This is a surprise to me. I thought we still supported Python 2.4
That's a surprise to me, too: I remember endless discussions about dropping support for Python 2.4 on this list, let me see:
https://mail.zope.org/pipermail/zope-dev/2009-April/036387.html
I thought the outcome was somehow that Python 2.4 support was dropped?
I recall the conclusion was not to do that yet.
But I'd appreciate it a lot, if I'm wrong on this! Do the tests pass with Python 2.4 for the ZTK?
I think we have a buildbot for it. http://dev.thehealthagency.com/buildbot/waterfall But I do see that Python 2.4 has a failed test, so we do need to fix that. Regards, Martijn
Martijn Faassen wrote: [snip]
But I do see that Python 2.4 has a failed test, so we do need to fix that.
Some of those failure appears to be because some code was switched over to the Python standard library pprint from the version in zope.testing, and in Python 2.4 that doesn't sort dictionaries. http://dev.thehealthagency.com/buildbot/builders/ztk%20slave-ubuntu32-py2.4/... We already talked about undeprecating that pprint function in zope.testing.doctestunit. It'd be nice if someone looked into doing that. Regards, Martijn
Am Dienstag 05 Januar 2010 14:37:51 schrieb Martijn Faassen:
Hermann Himmelbauer wrote:
Am Dienstag 05 Januar 2010 11:58:38 schrieb Martijn Faassen:
Hermann Himmelbauer wrote:
But I have to further state that I'm locked into Zope 3.4.0 as the support for Python 2.4 was dropped, so I can't upgrade to the current ZTK.
This is a surprise to me. I thought we still supported Python 2.4
That's a surprise to me, too: I remember endless discussions about dropping support for Python 2.4 on this list, let me see:
https://mail.zope.org/pipermail/zope-dev/2009-April/036387.html
I thought the outcome was somehow that Python 2.4 support was dropped?
I recall the conclusion was not to do that yet.
That's good news for me - don't know why I assumed that. What I currently don't understand is what the suggested upgrade path from KGS 3.4 is: Should I simply use the current packages from the SVN, hence drop the "versions=versions" directive from buildout.cfg? Best Regards, Hermann -- hermann@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7
2010/1/5 Hermann Himmelbauer <dusty@qwer.tk>:
Am Dienstag 05 Januar 2010 14:37:51 schrieb Martijn Faassen:
Hermann Himmelbauer wrote:
Am Dienstag 05 Januar 2010 11:58:38 schrieb Martijn Faassen:
Hermann Himmelbauer wrote:
But I have to further state that I'm locked into Zope 3.4.0 as the support for Python 2.4 was dropped, so I can't upgrade to the current ZTK.
This is a surprise to me. I thought we still supported Python 2.4
That's a surprise to me, too: I remember endless discussions about dropping support for Python 2.4 on this list, let me see:
https://mail.zope.org/pipermail/zope-dev/2009-April/036387.html
I thought the outcome was somehow that Python 2.4 support was dropped?
I recall the conclusion was not to do that yet.
That's good news for me - don't know why I assumed that.
Note that ZODB is dropping python 2.4 support in 3.10. https://mail.zope.org/pipermail/zodb-dev/2009-December/013084.html Laurence
Am Dienstag 05 Januar 2010 16:05:34 schrieb Laurence Rowe:
2010/1/5 Hermann Himmelbauer <dusty@qwer.tk>:
Am Dienstag 05 Januar 2010 14:37:51 schrieb Martijn Faassen:
Hermann Himmelbauer wrote:
Am Dienstag 05 Januar 2010 11:58:38 schrieb Martijn Faassen:
Hermann Himmelbauer wrote:
But I have to further state that I'm locked into Zope 3.4.0 as the support for Python 2.4 was dropped, so I can't upgrade to the current ZTK.
This is a surprise to me. I thought we still supported Python 2.4
That's a surprise to me, too: I remember endless discussions about dropping support for Python 2.4 on this list, let me see:
https://mail.zope.org/pipermail/zope-dev/2009-April/036387.html
I thought the outcome was somehow that Python 2.4 support was dropped?
I recall the conclusion was not to do that yet.
That's good news for me - don't know why I assumed that.
Note that ZODB is dropping python 2.4 support in 3.10. https://mail.zope.org/pipermail/zodb-dev/2009-December/013084.html
Hmmm. Bad luck for me. Thanks for the Info. Best Regards, Hermann -- hermann@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7
On Tue, Jan 5, 2010 at 16:10, Hermann Himmelbauer <dusty@qwer.tk> wrote:
Hmmm. Bad luck for me.
It would be interesting to know why you have to use Python 2.4. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lennart Regebro wrote:
On Tue, Jan 5, 2010 at 16:10, Hermann Himmelbauer <dusty@qwer.tk> wrote:
Hmmm. Bad luck for me.
It would be interesting to know why you have to use Python 2.4. Dropping Python 2.4 support asap for any module is basically a good thing. I encountered lately a serve issue within large unicode string in Python 2.4. The Python developers rejected the issue with wont-fix since Python 2.4 is no longer maintained...it's time to move on...
Andreas - -- ZOPYX Limited \ zopyx group Charlottenstr. 37/1 \ The full-service network for your D-72070 Tübingen \ Python, Zope and Plone projects www.zopyx.com, info@zopyx.com \ www.zopyxgroup.com - ------------------------------------------------------------------------ E-Publishing, Python, Zope & Plone development, Consulting -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktDWDkACgkQCJIWIbr9KYwOIwCfQVZfYFjHI6T1AyjtqyNpd5kQ VnUAoLLJu/z28JMuewQfD+2IjV+r6cKF =vmng -----END PGP SIGNATURE-----
Am Dienstag 05 Januar 2010 16:18:17 schrieb Andreas Jung:
Lennart Regebro wrote:
On Tue, Jan 5, 2010 at 16:10, Hermann Himmelbauer <dusty@qwer.tk>
wrote:
Hmmm. Bad luck for me.
It would be interesting to know why you have to use Python 2.4.
Dropping Python 2.4 support asap for any module is basically a good thing. I encountered lately a serve issue within large unicode string in Python 2.4. The Python developers rejected the issue with wont-fix since Python 2.4 is no longer maintained...it's time to move on...
Basically I agree. But in my case, it's quite hard to move on - at least for now... Best Regards, Hermann -- hermann@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7
Am Dienstag 05 Januar 2010 16:12:02 schrieb Lennart Regebro:
On Tue, Jan 5, 2010 at 16:10, Hermann Himmelbauer <dusty@qwer.tk> wrote:
Hmmm. Bad luck for me.
It would be interesting to know why you have to use Python 2.4.
My application relies on the MaxDB database (former SAP-DB). They offer a Python module which can only be imported with Python <= 2.4. I still hope that SAP releases a newer Python module, although they don't seem to do so soon. So the remaining alternative is to develop a DBAPI 2.0 compliant Python/MaxDB module by myself, which is, however, quite some work. Another alternative would be to switch over to PostgreSQL, but this is not yet possible. Btw., if you are interested, you can see the application here (an online banking for training firms): http://zis.act.at/bankneu/s/start Best Regards, Hermann -- hermann@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martijn Faassen wrote:
Hermann Himmelbauer wrote:
Am Dienstag 05 Januar 2010 11:58:38 schrieb Martijn Faassen:
Hermann Himmelbauer wrote:
But I have to further state that I'm locked into Zope 3.4.0 as the support for Python 2.4 was dropped, so I can't upgrade to the current ZTK. This is a surprise to me. I thought we still supported Python 2.4 That's a surprise to me, too: I remember endless discussions about dropping support for Python 2.4 on this list, let me see:
https://mail.zope.org/pipermail/zope-dev/2009-April/036387.html
I thought the outcome was somehow that Python 2.4 support was dropped?
I recall the conclusion was not to do that yet.
Mailman says that you argued[1] for keeping 2.4 compatibility only for zope.interface and zope.component. I argued for keeping it for the whole "bicycle-seat toolkit"[2].
But I'd appreciate it a lot, if I'm wrong on this! Do the tests pass with Python 2.4 for the ZTK?
I think we have a buildbot for it.
http://dev.thehealthagency.com/buildbot/waterfall
But I do see that Python 2.4 has a failed test, so we do need to fix that.
Which job? There are a bunch of red ones, as well as a bunch of offlines. A waterfall which doesn't stay green most of the time is not very helpful. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktDxJ8ACgkQ+gerLs4ltQ6NEwCg3RNgOSmtziM5KRveDjL2dp37 yywAn2gjkzFNSb1abrJJQSwUo0UJ0qda =+B2p -----END PGP SIGNATURE-----
Hey Tres, Tres Seaver wrote:
You're kidding, right? [snip] My self-interest? Not really: you are appealing to my altruism, in the fact that I care about the *broader* Zope community (broader than Zope2, Grok, Plone, or whatever. Neither of my chosen platforms (Zope2, bfg) rely any longer on any of thsoe pacakages at all, which makes my direct interest in them exactly zero.
Basically we all worked together for a year. Now Zope 2 happens to be done first moving off zope.app, so you're telling me f$%#%Q#k you, I don't need you anymore, go away. Thanks. Martijn
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martijn Faassen wrote:
Hey Tres,
Tres Seaver wrote:
You're kidding, right? [snip] My self-interest? Not really: you are appealing to my altruism, in the fact that I care about the *broader* Zope community (broader than Zope2, Grok, Plone, or whatever. Neither of my chosen platforms (Zope2, bfg) rely any longer on any of thsoe pacakages at all, which makes my direct interest in them exactly zero.
Basically we all worked together for a year. Now Zope 2 happens to be done first moving off zope.app, so you're telling me f$%#%Q#k you, I don't need you anymore, go away.
That's not what he is telling you. I don't think he ever intentionally "worked together" to support zope.app* packages in any way. If anything, he may have had input into and interest in the "small ZTK" packages and/or direction, so his viewpoint has never changed. My own perspective on this issue is similar, with the difference that my list of chosen platforms is just Zope 2 at the moment. I'm also sharing his belief that we're having a serious disconnect between your expectation in regards to zope.app and how it should continue and our belief what the ZTK was and should be. However, none of this should lead to swearing. jens -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAktDIl4ACgkQRAx5nvEhZLJAPACeOje6/JQC9uKzPr/YknuZzyTw nCUAnili87j/qKjQu0EgdwnMZebLUd0u =SeE8 -----END PGP SIGNATURE-----
Jens Vagelpohl wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Martijn Faassen wrote:
Hey Tres,
Tres Seaver wrote:
You're kidding, right? [snip] My self-interest? Not really: you are appealing to my altruism, in the fact that I care about the *broader* Zope community (broader than Zope2, Grok, Plone, or whatever. Neither of my chosen platforms (Zope2, bfg) rely any longer on any of thsoe pacakages at all, which makes my direct interest in them exactly zero. Basically we all worked together for a year. Now Zope 2 happens to be done first moving off zope.app, so you're telling me f$%#%Q#k you, I don't need you anymore, go away.
That's not what he is telling you. I don't think he ever intentionally "worked together" to support zope.app* packages in any way. If anything, he may have had input into and interest in the "small ZTK" packages and/or direction, so his viewpoint has never changed.
Well, Zope 2 released with a smaller but present dependency on zope.app some time ago. Those zope.app packages were at least until then relevant to Zope 2 developers. If support for them had been dropped by someone then, they would have had to pick up maintaining them themselves, if they wanted to continue tracking the ZTK and give Zope 2 users an upgrade path out of zope.app. Whether they are still relevant today is harder to say as Zope 2 already had some transition time behind it. Regards, Martijn
Martijn Faassen wrote:
Hey Tres,
Tres Seaver wrote:
You're kidding, right? [snip] My self-interest? Not really: you are appealing to my altruism, in the fact that I care about the *broader* Zope community (broader than Zope2, Grok, Plone, or whatever. Neither of my chosen platforms (Zope2, bfg) rely any longer on any of thsoe pacakages at all, which makes my direct interest in them exactly zero.
Basically we all worked together for a year. Now Zope 2 happens to be done first moving off zope.app, so you're telling me f$%#%Q#k you, I don't need you anymore, go away.
In a strange twist of fate, I find myself agreeing with your position and disagreeing with your style. Take a deep breath, Martijn. People may argue passionately, but they're not doing anything like what you imply with punctuation, and this type of escalation is very counter-productive. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martijn Faassen wrote:
Hey Tres,
Tres Seaver wrote:
You're kidding, right? [snip] My self-interest? Not really: you are appealing to my altruism, in the fact that I care about the *broader* Zope community (broader than Zope2, Grok, Plone, or whatever. Neither of my chosen platforms (Zope2, bfg) rely any longer on any of thsoe pacakages at all, which makes my direct interest in them exactly zero.
Basically we all worked together for a year. Now Zope 2 happens to be done first moving off zope.app, so you're telling me f$%#%Q#k you, I don't need you anymore, go away.
I don't mean to say anything like that: my contention is that the non-zope.app ZTK packages no longer have any dependencies on zope.app, which removes the only technical reason to keep them in the toolkit. A lot of the drive for that cleanup is the efforts from the Zope2 side to track down and eradicate those dependencies, because the Zope2 developers have had an explicit "zope.app delenda est"-geddon running for months now. I don't mean to shaft folks who are still depending on some subset of the zope.app packages: I'm just puzzled by the notion that they belong in the ZTK for any reason other than the ZTK's own internal testing dependencies, or that keeping them there helps anybody. Until last week, Up through the 2.12 release line, Zope2 has been happily consuming a non-ZTK subset of those packages (different pins than the ZTK trunk in some cases). Grok has a similar fork / subset in its own versions.cfg: figuring out which of the packages listed there are actual requirements for Grok is not a task I can devote any time to, but should be on the "front burner" for the Grok developers who are thinking about transitioning to the ZTK. I do think your zopeapp solution may have some appeal for various framework developers trying to transition to the pared-down ZTK, but I don't have any plans to devote any proactive bandwidth to that effort (as opposed to answering questions or helping resolve issues raised by people who are working with it). Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktD0OsACgkQ+gerLs4ltQ7c6wCePZ0QpgU2Xp4riu9YdIg6yjka 3bIAoKjaj6RwsYjp770z1bj2kWeMSsi7 =iFqa -----END PGP SIGNATURE-----
Hi Tres, You don't seem to get what I kept telling you over and over. I'm therefore going to be more blunt. I don't want to use zope.app packages in Grok. Grok wants to get rid of zope.app packages. That's the very idea. We pushed this from the start. I spent a huge amount of time to make this possible, just like everyone else. But Grok isn't there yet. Neither are people who have to maintain Zope 3 apps. But I have to use zope.app packages in Grok 1.1, because people need to have a way to move off zope.app in a working system. It will be the equivalent, I believe, of Zope 2.12, though the details are different. We cannot ask users to switch their imports in Grok 1.0, as there, for instance, zope.app.container is the only thing that exists. There is no zope.container yet to switch your imports to. I am not asking you to help me maintain zope.app packages until the end of time. I'm asking you to help me support backwards compatibility code in zope.app for a while longer, until I and others have transitioned away from those packages as well. If that code goes untested, it breaks. It already started breaking. Jan-Wijbrand noticed test failures on zope.app.exception, just checking it out from svn.zope.org. He didn't know a zope.publisher 3.12 was released that created this breakage. He didn't even pin down the ZTK or anything; it was just a checkout using the most recent releases. The person who makes the change in the original package is likely able to identify the cause for such breakage much more easily, and either warn people about what to do, or make a quick fix himself. So I'm using zope.app packages, and changes happen in the zope.* subset, and zope.app packages are now breaking in SVN when buildouts are run. Until recently Zope 2 used zope.app packages too, for backwards compatibility reasons. If the situation had been reversed and Grok had been off zope.app first, I don't think you would have been very happy if suddenly these started breaking as they became unmaintained. Zope 2 is able to move off it more easily for a variety of reasons. Now that you're done, but we aren't yet, I am hearing a loud "screw you, we're done, we don't care about you anymore" from you. That really pisses me off. It's also just plain stupid if you only a little bit enlightened in your self-interest and want the ZTK to succeed and people outside the Zope 2 community to use it. You're making that a lot harder. You're making my lots life harder for short-term selfish reasons. And it makes me really want to say "screw you too". But that would not be very enlightened. Regards, Martijn
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martijn Faassen wrote:
You don't seem to get what I kept telling you over and over. I'm therefore going to be more blunt.
I don't want to use zope.app packages in Grok. Grok wants to get rid of zope.app packages. That's the very idea. We pushed this from the start. I spent a huge amount of time to make this possible, just like everyone else. But Grok isn't there yet. Neither are people who have to maintain Zope 3 apps.
Sure, I hear you on that.
But I have to use zope.app packages in Grok 1.1, because people need to have a way to move off zope.app in a working system. It will be the equivalent, I believe, of Zope 2.12, though the details are different. We cannot ask users to switch their imports in Grok 1.0, as there, for instance, zope.app.container is the only thing that exists. There is no zope.container yet to switch your imports to.
And the versions.cfg maintained on the Grok trunk reflects that, right? I believe (without verification) that the list of zope.app packages there is actually bigger than what Grok needs in and of itself at this point.
I am not asking you to help me maintain zope.app packages until the end of time. I'm asking you to help me support backwards compatibility code in zope.app for a while longer, until I and others have transitioned away from those packages as well.
I'm not going to put proactive effort into maintaining those packages. I will be glad to help other developers who run into such issues diagnose them, and work out reasonable solutions for them, largely through discussions on this list.
If that code goes untested, it breaks. It already started breaking. Jan-Wijbrand noticed test failures on zope.app.exception, just checking it out from svn.zope.org. He didn't know a zope.publisher 3.12 was released that created this breakage. He didn't even pin down the ZTK or anything; it was just a checkout using the most recent releases. The person who makes the change in the original package is likely able to identify the cause for such breakage much more easily, and either warn people about what to do, or make a quick fix himself.
Getting the buildbots to be nearly-always-green, and then whine when anything goes red, is the only way I know of to ensure that such breakage will be detected and reesolved quickly. If I commit a change to a non-zope.app package which causes a zope.app-dependent build to go red, then I certainly expect to help the developers responsible for the package set of the red build figure out out to fix it. Unless they bring the issue up, however, I'm gonna remain blissfully ignorant.
So I'm using zope.app packages, and changes happen in the zope.* subset, and zope.app packages are now breaking in SVN when buildouts are run.
Until recently Zope 2 used zope.app packages too, for backwards compatibility reasons. If the situation had been reversed and Grok had been off zope.app first, I don't think you would have been very happy if suddenly these started breaking as they became unmaintained.
It used a subset of them which were *not* kept up to date with the ZTK. Please see the versions.cfg on the Zope 2.12 branch, and compare with the ZTK trunk: http://svn.zope.org/Zope/branches/2.12/versions.cfg?rev=107345 http://svn.zope.org/*checkout*/zopetoolkit/trunk/ztk.cfg?rev=107719 In effect, none of the "KGS" provided by the ZTK has been in use by ZOpe2 for a long while: one of the reasons I cheered Hanno's work was that it finally got Zope2 to use the ZTK *directly*, rather than via a fork.
Zope 2 is able to move off it more easily for a variety of reasons. Now that you're done, but we aren't yet, I am hearing a loud "screw you, we're done, we don't care about you anymore" from you.
Please don't put words in my mouth.
That really pisses me off.
It's also just plain stupid if you only a little bit enlightened in your self-interest and want the ZTK to succeed and people outside the Zope 2 community to use it. You're making that a lot harder. You're making my lots life harder for short-term selfish reasons. And it makes me really want to say "screw you too". But that would not be very enlightened.
I want the ZTK to succeed: indeed, I have been working to position it such that it might be useful even outside the bounds of the current Zope community: I think that moving the zope.app packages out of the ZTK proper is the best possible thing we can do to move it towards success. I don't see how I'm making your life harder here: the zopeapp spinoff you created gives folks who still need a managed set of those packages a place to stand, while at the same time removing the burden of their maintenance from the toolkit. I never said that I wouldn't listen to feedback from consumers of zopeapp who discovered a problem introduced by a change in the ZTK. In fact, I have said repeatedly that I want real users report such problems, and would gladly help those developers deal with them. What I don't want to be held responsible for is "hypothetical" breakage, and I'm certainly not going to be on the hook to find such breakage myself in packages I don't use. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktD1dkACgkQ+gerLs4ltQ4qcgCffy06cvMBFyCmr6yzDUkQ0Nek OIkAoKZWs+8RXIw6VT0+MU06HEr2JJCV =EYrr -----END PGP SIGNATURE-----
Am Montag 04 Januar 2010 23:10:05 schrieb Tres Seaver:
Martijn Faassen wrote:
Obviously I cannot *force* ZTK maintainers to worry about this. Instead I'm appealing to your self-interest. And of course the transition burden is shared and should not fall solely or even predominantly on the ZTK maintainers.
My self-interest? Not really: you are appealing to my altruism, in the fact that I care about the *broader* Zope community (broader than Zope2, Grok, Plone, or whatever. Neither of my chosen platforms (Zope2, bfg) rely any longer on any of thsoe pacakages at all, which makes my direct interest in them exactly zero.
If the ZTK is decoupled from other users, e.g. from people who rely on zope.app, then they will simply not use it, or do a fork. This way, ZTK users are lost, which also leads to a loss of supporters and developers and results in a shrinking interest in ZTK, whose primary goal was/is to be _the_ base for all other Zope-based applications. So I think, being altruistic may be quite the same as acting out of self-interest. Best Regards, Hermann -- hermann@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hermann Himmelbauer wrote:
Am Montag 04 Januar 2010 23:10:05 schrieb Tres Seaver:
Martijn Faassen wrote:
Obviously I cannot *force* ZTK maintainers to worry about this. Instead I'm appealing to your self-interest. And of course the transition burden is shared and should not fall solely or even predominantly on the ZTK maintainers. My self-interest? Not really: you are appealing to my altruism, in the fact that I care about the *broader* Zope community (broader than Zope2, Grok, Plone, or whatever. Neither of my chosen platforms (Zope2, bfg) rely any longer on any of thsoe pacakages at all, which makes my direct interest in them exactly zero.
If the ZTK is decoupled from other users, e.g. from people who rely on zope.app, then they will simply not use it, or do a fork.
This way, ZTK users are lost, which also leads to a loss of supporters and developers and results in a shrinking interest in ZTK, whose primary goal was/is to be _the_ base for all other Zope-based applications.
How is that any different from people who won't use the ZTK because they don't want to deal with any zope.app* baggage? jens -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAktDOoMACgkQRAx5nvEhZLJKSwCgiQc3RIgtiDrL+CPib5mMr0WM /aoAoKNl0YZCL7B78Q8fp53xn8UecQF5 =X5h+ -----END PGP SIGNATURE-----
Jens Vagelpohl wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hermann Himmelbauer wrote:
Am Montag 04 Januar 2010 23:10:05 schrieb Tres Seaver:
Martijn Faassen wrote:
Obviously I cannot *force* ZTK maintainers to worry about this. Instead I'm appealing to your self-interest. And of course the transition burden is shared and should not fall solely or even predominantly on the ZTK maintainers. My self-interest? Not really: you are appealing to my altruism, in the fact that I care about the *broader* Zope community (broader than Zope2, Grok, Plone, or whatever. Neither of my chosen platforms (Zope2, bfg) rely any longer on any of thsoe pacakages at all, which makes my direct interest in them exactly zero. If the ZTK is decoupled from other users, e.g. from people who rely on zope.app, then they will simply not use it, or do a fork.
This way, ZTK users are lost, which also leads to a loss of supporters and developers and results in a shrinking interest in ZTK, whose primary goal was/is to be _the_ base for all other Zope-based applications.
How is that any different from people who won't use the ZTK because they don't want to deal with any zope.app* baggage?
We were all together carrying the old zope.app* baggage for reasons of transitioning out of it. Then one of the party managed to transition out of it first. So without warning, they dropped the baggage and ran away as fast as they could. :) Regards, Martijn
Jens Vagelpohl wrote:
How is that any different from people who won't use the ZTK because they don't want to deal with any zope.app* baggage?
We have a proposal for dealing with that now: To maintain two KGS', one for ZTK and one for ZopeApp. We can and should run tests for both, and ensure that ZopeApp depends on the appropriate ZTK release. This way, if a ZTK package is changed in a way that breaks ZopeApp, at least we'll know. We have a number of people who have a stake in ZopeApp and are willing to help maintain it. We also have a history of people maintaining libraries caring about their consumers. You are the poster child for that, I think, being immensely helpful with CMF releases for the purposes of Plone. I don't see this being any different. I think everyone agrees that: - zope.app.* is not very interesting to anyone other than possibly a subset being useful in Zope3/BlueBream/wahteveritgetscalled. - We clearly had people using "some subset of Zope 3" for ages, long before the ZTK concept existed. - Ergo, we have a *lot* of zope.app.* imports in the wild. - We tried to arrive at a common subset we could collectively maintain to make all our lives easier and called that ZTK. - We agree that ZTK should not have zope.app.* packages in it, or indeed other "less useful" zope.* packages. - We have a number of frameworks trying to move towards using the ZTK. - Those frameworks are in various states of completion towards that goal. - The shape of the ZTK itself is influenced by that process of dependency untangling that allows frameworks to move towards adopting it. Thus we have a two-way process of changes flowing between the ZTK itself and the various consumers or would-be consumers. This was evidenced when Hanno removed zope.app.* packages from the ZTK. That helped the ZTK towards it end goal, but it also caused pain for people whose frameworks are less advanced in that goal and may need zope.app.* for a while longer. - Waking up one morning to find your buildout going crazy and having to backtrack in svn to find out what the KGS used to be and piecing it together is not nice. - There's benefit in having a tested set of zope.app.* packages and testing that against the ZTK, so that when ZTK developers break a zope.app.* package *that is currently used by someone*, they can at least be aware of that. - This situation may go away in the near-to-mid-term future when (a) the major frameworks have managed to get a release out that uses the ZTK proper without zope.app.* and/or (b) someone decides to actually love some subset of zope.app.*. That "someone" is likely BlueBream or whatever. So, in short: - No-one wants zope.app.* in the ZTK. - zope.app.* exists in the wild today, in real projects, for real users, who we are going to ask to upgrade to some ZTK supported release of their framework soon. - Some people were disadvantaged when it disappeared over night and need a bit more time/help to get there. - Most/all people would like us to try to work together for mutual benefit. The proposal to have a ZopeApp KGS with a buildbot and a dependency on ZTK is perfectly reasonable. In the worst case scenario, those self-styled ZTK maintainers who don't want to ever see zope.app.* again will have a little bit of guilt because they broke other people's code. In the best case, we'll work together to fix those breakages, or identify that no-one cares about a particular zope.app.* and kill it from ZopeApp forever. Somehow, we all lost our cool at around the same time. Let's stop the non-factual discussions and think about what people actually *need* to get their jobs done, and find out who has interest and capacity to support that. And please, let's stop making this an "everyone vs. Martijn" debate, because apart from a few lapses in style, he's actually making a lot of sense and speaking for real people with real needs. I'll count myself as one of them to shut up any debate about whether such people really exist. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
On Sunday 03 January 2010, Martijn Faassen wrote:
So here's my proposed solution for the ZTK shrinking issue:
I really like the proposed solution of the small ZTK and an addon zope.app superset. It provides me with an example how to create other supersets. And I do agree that a migration path and some longer-term support is very, very important. Regards, Stephan -- Entrepreneur and Software Geek Google me. "Zope Stephan Richter"
On Sun, Jan 3, 2010 at 3:51 PM, Martijn Faassen <faassen@startifact.com> wrote:
Hi there,
So here's my proposed solution for the ZTK shrinking issue:
The ZTK branch 'faassen-smaller' contains Hanno's smaller ZTK. Since Zope 2 forked the ZTK in response and continued to make changes to their fork, I've tried to keep it in sync with the Zope 2 fork.
I've created a new 'zopeapp' package that expands the ZTK with zope.app. packages in my sandbox. This extracts that information from the ZTK.
Hopefully after we get some feedback from other steering group members (very silent indeed in the holiday period when all this happened) we can make these two projects the official one: a ZTK project and a zopeapp project.
A few things I ask the ZTK maintainers:
I ask the ZTK maintainers to have the same concern for the zope.app packages as for any other user of the ZTK: work to support zopeapp's compatibility with the ZTK. If the zopeapp maintainers have issues, listen to them seriously. I think everybody can agree that this is within the ZTK mandate for the time being, as zopeapp clearly exists and is being used by a significant amount of people. (I'd like to work to retire it by making it used by far less people)
I also strongly encourage the ZTK maintainers to consider the situation of backwards compatibility seriously. Help people transition from their code now to the ZTK. Helping everybody migrate to the ZTK smoothly increases the value of the ZTK itself. Obviously I cannot *force* ZTK maintainers to worry about this. Instead I'm appealing to your self-interest. And of course the transition burden is shared and should not fall solely or even predominantly on the ZTK maintainers.
I also think we as ZTK maintainers should better consider the concerns of other users of the ZTK. In this case, Zope 2 had less of a concern for zope.app than Grok or Zope 3. I didn't even understand this until the debate was further along. The concerns of others should be considered as well instead of simply rejected. We usually can find ways to balance the concerns of everybody. To that end concerns (or lack thereof) should be clearly communicated and be listened to.
Big +1 from me. I'd especially like to encourage emphasis on backward compatibility. This is key for us. Some specific advice: - When we refactor zope.app.foo to be zope.foo (or something else), rather than changing zope.app.foo to use zope.foo, just leave zope.app.foo alone, if possible. - When we "clean up" and existing package without creating a new one in a way that is backward incompatible, let's update the major version number. Jim -- Jim Fulton
Jim Fulton wrote:
- When we refactor zope.app.foo to be zope.foo (or something else), rather than changing zope.app.foo to use zope.foo, just leave zope.app.foo alone, if possible.
One problem with this is that if you have interfaces for which there are components registered, this can make it impossible to support both packages. For example, zope.app.container had IObjectAddedEvent. This is now in zope.lifecycleevent (it spent some time in zope.container, too, I think). If I have a system where some packages use the "new" zope.lifecycleevent and fire events from there, and I have an event handler registered for zope.app.container.interfaces.IObjectAddedEvent, that won't get called, unless zope.app.container.interfaces.IObjectAddedEvent is a compatibility import for zope.lifecycleevent.IObjectAddedEvent. This happened in Plone, by the way, when people started using things like z3c.form. So we certainly appreciated people changing zope.app.* in tandem with the refactoring. :) Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
participants (11)
-
Andreas Jung -
Hermann Himmelbauer -
Jens Vagelpohl -
Jim Fulton -
Laurence Rowe -
Lennart Regebro -
Martijn Faassen -
Martin Aspeli -
Stephan Richter -
Takeshi Yamamoto -
Tres Seaver