Re: [Zope-dev] Hanno, please update the ZTK
On Sun, May 2, 2010 at 10:52 PM, Martijn Faassen faas...@startifact.com wrote: Hi there, Of course what applies to Hanno should apply to others making releases of packages maintained by the Zope Toolkit project as well. I think the ZTK leadership should figure out some kind of guidelines for this that people can follow. Maybe someone can write a tool too to check up how far a toolkit is out of sync with the latest releases. Just some ideas. For the tool, I think I did it already. I modified one of Hanno's script some times ago: cd zopetoolkit/trunk bin/buildout -c checknew.cfg bin/python checknew.py Vincent ___ 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] zope.exceptiosn release has no relaese date
Lennart Regebro wrote: I thought it was painless already, but maybe I was wrong. :) It's very nice to be able to do a full release by just typing 'fullrelease' and saying 'yes' a number of times. The tool made a convert out of me, and I know others who also were pleased by how much it sped things up, even though, as I was, they were initially somewhat skeptical. 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] Hanno, please update the ZTK
Vincent Fretin wrote: For the tool, I think I did it already. I modified one of Hanno's script some times ago: cd zopetoolkit/trunk bin/buildout -c checknew.cfg bin/python checknew.py Cool! This tool should be documented if it isn't already. Why is this in a separate .cfg unlike the other tools that come with the ZTK? Unless creating this extra script is very expensive, I think it makes sense to generate it in 'bin' along with the rest of the scripts. 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] Hanno, please update the ZTK
Hanno Schlichting wrote: Good evening :) If you have a specific issue with me, you might contact me in private. But with your follow-ups this turned into a more general issue. No, I think this needs to be public as the ZTK is a public project that I care about. And you're not playing your proper part in it. You're not going to listen to me (otherwise the fork would never have happened; you had an issue with listening to me), so I'm informing the rest of the community. Maybe you'll listen to them. The fork is counterproductive. And it's just annoying me. It's time for this annoyance to disappear. 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] Hanno, please update the ZTK
On 5/3/10 12:20 , Martijn Faassen wrote: Hanno Schlichting wrote: Good evening :) If you have a specific issue with me, you might contact me in private. But with your follow-ups this turned into a more general issue. No, I think this needs to be public as the ZTK is a public project that I care about. And you're not playing your proper part in it. You're not going to listen to me (otherwise the fork would never have happened; you had an issue with listening to me), so I'm informing the rest of the community. Maybe you'll listen to them. The fork is counterproductive. And it's just annoying me. It's time for this annoyance to disappear. Can we please not rehash an old discussion or make this personal? This has all been discussed too often already. 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] Hanno, please update the ZTK
Hi there, Hanno Schlichting wrote: I expect us to define the process around package releases and updating the ZTK. It's not entirely clear to me who should and who is allowed to update the ZTK definition. We'll figure things out and once we have I'll stick to the rules. My few cents: I think everybody should be allowed to update the ZTK definition. They should follow certain guidelines (run tests, and such. Maybe updating a changelog is a good idea too). Stability can be taken care of by branching and tagging. I.e. the same guidelines as we have for other pieces of code can be a good starting point. To get back to the discussion that caused the fork. We have implicit, but I think widely understood and accepted, rules about backwards compatibility. So we don't expect someone to rip out half the code of a Python package just like that. Generally we expect the tests to continue to run. Similarly we shouldn't just drop things from the ZTK without special action (this involves removing tests too!). We started to try to spell some of that out here long ago: http://docs.zope.org/zopetoolkit/about/coreextra.html But I'd hate it if the ZTK trunk became some kind of bureaucratic maze, as it'd stop me from getting work done. 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] Hanno, please update the ZTK
On 5/3/10 12:34 , Martijn Faassen wrote: Hi there, Hanno Schlichting wrote: I expect us to define the process around package releases and updating the ZTK. It's not entirely clear to me who should and who is allowed to update the ZTK definition. We'll figure things out and once we have I'll stick to the rules. My few cents: I think everybody should be allowed to update the ZTK definition. They should follow certain guidelines (run tests, and such. Maybe updating a changelog is a good idea too). Stability can be taken care of by branching and tagging. I.e. the same guidelines as we have for other pieces of code can be a good starting point. To get back to the discussion that caused the fork. We have implicit, but I think widely understood and accepted, rules about backwards compatibility. So we don't expect someone to rip out half the code of a Python package just like that. Generally we expect the tests to continue to run. Similarly we shouldn't just drop things from the ZTK without special action (this involves removing tests too!). We started to try to spell some of that out here long ago: http://docs.zope.org/zopetoolkit/about/coreextra.html But I'd hate it if the ZTK trunk became some kind of bureaucratic maze, as it'd stop me from getting work done. I suggest that we wait impatiently for the ZTK steering committee to come up with a useful policy instead of trying to do their work when none of us volunteered for the task. 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] Hanno, please update the ZTK
Wichert Akkerman wrote: Can we please not rehash an old discussion or make this personal? This has all been discussed too often already. As far as I know, I've *never* discussed this fork on this list, but I might be wrong; feel free to dig the archives. But that doesn't matter: the fork is still there. So: wtf, Wichert? There is a fork of the ZTK being maintained today, right now. I want it to stop. Hanno, please stop the fork. I don't know what Hanno is trying to pull by saying he's going to look into the ZTK. He helped build the ZTK, and then he forked it, which took all of 5 minutes, and now 4 months down the road he's looking into the ZTK? I think it shouldn't take more than 10 minutes to unfork it. And if someone else is maintaining a fork of the ZTK, I'll be happy to single out that individual too. Feel free to fork the ZTK, Wichert, and I'll be complaining about *you*. If I fork the ZTK you get to complain about me. But you didn't, I didn't, but Hanno did. 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] Hanno, please update the ZTK
Wichert Akkerman wrote: I suggest that we wait impatiently for the ZTK steering committee to come up with a useful policy instead of trying to do their work when none of us volunteered for the task. I don't understand your suggestion. Could you rephrase it? I'm a ZTK user, and I'm dissatisfied. I'm complaining. What's more, I'm actually offering constructive suggestions. Are you? 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] Hanno, please update the ZTK
On 5/3/10 12:52 , Martijn Faassen wrote: Wichert Akkerman wrote: I suggest that we wait impatiently for the ZTK steering committee to come up with a useful policy instead of trying to do their work when none of us volunteered for the task. I don't understand your suggestion. Could you rephrase it? I'm a ZTK user, and I'm dissatisfied. I'm complaining. What's more, I'm actually offering constructive suggestions. Are you? A ZTK steering group was created to help define and manage the ZTK. You did not volunteer for that, and neither did I. Hanno did, so why not let him do his job instead of distracting him by rehashing a discussion that already happened on this list. 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] Hanno, please update the ZTK
Martijn Faassen wrote: [snip] Why is this in a separate .cfg unlike the other tools that come with the ZTK? Unless creating this extra script is very expensive, I think it makes sense to generate it in 'bin' along with the rest of the scripts. To expand on that, it'd be nice if it were also easy to integrate in other toolkits such as the Grok toolkit. I imagine the BlueBream people would also like to have such a thing. The other scripts (such as the cool depgraph stuff that Hanno created) are reusable in that way, and it's been very nice. 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] Hanno, please update the ZTK
Wichert Akkerman wrote: On 5/3/10 12:51 , Martijn Faassen wrote: Wichert Akkerman wrote: Can we please not rehash an old discussion or make this personal? This has all been discussed too often already. As far as I know, I've *never* discussed this fork on this list, but I might be wrong; feel free to dig the archives. But that doesn't matter: the fork is still there. So: wtf, Wichert? Perhaps you haven't, but others have discussed the reason the fork was cerated and why it still exists. Since then many things have happened including the creation of the ZTK steering group, of which Hanno is a member. The ZTK steering group was created about a year ago, so I'm not sure what you're trying to suggest here. I just hope you're not suggesting I didn't do anything in 2009. By the way: at the time I invited Hanno into the group, but he declined then, and I respect that, but just so you know. I must say it totally baffles me that the ZTK was acceptable to Zope 2 until january, and became unacceptable at that point. All answers are probably in that mailing list thread, but I can't be bothered to look it up. Please just make the fork go away. 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] Hanno, please update the ZTK
On 5/3/10 13:07 , Martijn Faassen wrote: Wichert Akkerman wrote: On 5/3/10 12:51 , Martijn Faassen wrote: Wichert Akkerman wrote: Can we please not rehash an old discussion or make this personal? This has all been discussed too often already. As far as I know, I've *never* discussed this fork on this list, but I might be wrong; feel free to dig the archives. But that doesn't matter: the fork is still there. So: wtf, Wichert? Perhaps you haven't, but others have discussed the reason the fork was cerated and why it still exists. Since then many things have happened including the creation of the ZTK steering group, of which Hanno is a member. The ZTK steering group was created about a year ago, so I'm not sure what you're trying to suggest here. Sorry, my mistake. I meant the ZTK release manage group, not the now defunct ZTK steering group, I must say it totally baffles me that the ZTK was acceptable to Zope 2 until january, and became unacceptable at that point. All answers are probably in that mailing list thread, but I can't be bothered to look it up. Please just make the fork go away. The needed steps to do that can be found in the list archives. 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] Hanno, please update the ZTK
Wichert Akkerman wrote: On 5/3/10 12:52 , Martijn Faassen wrote: Wichert Akkerman wrote: I suggest that we wait impatiently for the ZTK steering committee to come up with a useful policy instead of trying to do their work when none of us volunteered for the task. I don't understand your suggestion. Could you rephrase it? I'm a ZTK user, and I'm dissatisfied. I'm complaining. What's more, I'm actually offering constructive suggestions. Are you? A ZTK steering group was created to help define and manage the ZTK. You did not volunteer for that, and neither did I. Hanno did, so why not let him do his job instead of distracting him by rehashing a discussion that already happened on this list. I'm a ZTK user. I thought this was the mailing list for ZTK users to bring up issues they have? Am I to understand that this open source project works in such a way that we can't even say anything until the steering group is done coming up with guidelines? How *do* I ask the steering group for things? Are suggestions really off the table? I think you should explain things better to newcomers such as me. :) Last year you weren't so overly protective of the ZTK steering group. What's more, you sound like you think the ZTK steering group formed this year! Wow. You seem to have forgotten 2009 already? I'd be mightily pissed off that you're ignoring my hard work last year if it weren't so hilariously silly. :) Maybe you're worried I'm trying to take over. I'm not, I'm just a user and contributor to this project. Anyway, I didn't realize the steering group got disbanded and reformed; the Zope Toolkit documentation still seems to refer to the old steering group: http://docs.zope.org/zopetoolkit/steeringgroup/members.html Someone should update it. That way people don't have to go through the mailing list archives to find decisions. This was something that the 2009 incarnation of the steering group was trying to do and I think the 2010 version would do well to emulate that, while of course trying to improve on the things that didn't work so well last year. 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] Hanno, please update the ZTK
Wichert Akkerman wrote: Sorry, my mistake. I meant the ZTK release manage group, not the now defunct ZTK steering group, If it's defunct someone better update the documentation. 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] zope.exceptiosn release has no relaese date
On Mon, May 3, 2010 at 3:46 PM, Martijn Faassen faas...@startifact.com wrote: Lennart Regebro wrote: I thought it was painless already, but maybe I was wrong. :) It's very nice to be able to do a full release by just typing 'fullrelease' and saying 'yes' a number of times. The tool made a convert out of me, and I know others who also were pleased by how much it sped things up, even though, as I was, they were initially somewhat skeptical. I am a happy user of zest.releaser (Thanks to the developers!) It made release of bluebream (PasteScript based project template) package very easy. I can do a full release within 1 minute ! Regards, Baiju M ___ 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] Zope Tests: 10 OK, 4 Failed, 2 Unknown
Summary of messages to the zope-tests list. Period Sun May 2 12:00:00 2010 UTC to Mon May 3 12:00:00 2010 UTC. There were 16 messages: 6 from Zope Tests, 9 from ccomb at free.fr, 1 from ct at gocept.com. Test failures - Subject: FAILED: Repository policy check found errors in 670 projects From: ct at gocept.com Date: Sun May 2 21:17:48 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-May/014232.html Subject: FAILED : ZTK 1.0dev / Python2.4.6 Linux 32bit From: ccomb at free.fr Date: Mon May 3 00:04:42 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-May/014243.html Subject: FAILED : Zope 3.4.1 KGS / Python2.4.6 32bit linux From: ccomb at free.fr Date: Mon May 3 00:27:11 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-May/014246.html Subject: FAILED : Zope 3.4.1 KGS / Python2.5.2 32bit linux From: ccomb at free.fr Date: Mon May 3 00:51:14 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-May/014247.html Unknown --- Subject: UNKNOWN : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Sun May 2 21:32:41 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-May/014235.html Subject: UNKNOWN : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Sun May 2 21:34:41 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-May/014236.html Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Sun May 2 21:28:41 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-May/014233.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Sun May 2 21:30:41 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-May/014234.html Subject: OK : Zope-trunk Python-2.6.4 : Linux From: Zope Tests Date: Sun May 2 21:36:41 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-May/014237.html Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux From: Zope Tests Date: Sun May 2 21:38:41 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-May/014238.html Subject: OK : BlueBream template / Python2.7b1 32bit linux From: ccomb at free.fr Date: Sun May 2 22:00:53 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-May/014239.html Subject: OK : BlueBream template / Python2.6.4 32bit linux From: ccomb at free.fr Date: Sun May 2 22:00:57 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-May/014241.html Subject: OK : BlueBream template / Python2.5.2 32bit linux From: ccomb at free.fr Date: Sun May 2 22:00:58 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-May/014240.html Subject: OK : BlueBream template / Python2.4.6 32bit linux From: ccomb at free.fr Date: Sun May 2 22:00:58 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-May/014242.html Subject: OK : ZTK 1.0dev / Python2.5.2 Linux 32bit From: ccomb at free.fr Date: Mon May 3 00:06:09 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-May/014244.html Subject: OK : ZTK 1.0dev / Python2.6.4 Linux 32bit From: ccomb at free.fr Date: Mon May 3 00:06:19 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-May/014245.html ___ 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] summary of suggestions
Hi there, Because my suggestions (besides the fork issue) as a ZTK user/contributor were scattered through the thread, here's a handy summary: * please construct guidelines for updating the ZTK when making a release of a package that's managed by the ZTK project. It's useful people test their changes within the ZTK. * please let these guidelines not block most updates by most people most of the time; it should be easy to update the ZTK. Gatekeepers tend to slow things down a lot, and we don't have them for most Python code. * there's a 'checknew.py' script to see whether there are releases newer than the ZTK. I'd be useful if this were integrated in the standard ZTK buildout.cfg so you just get a 'bin/checknew'. It'd also be nice if that were reusable by other toolkit projects. * (new idea) similarly it'd be nice if there were a script integrated that could check which binary egg releases exist for Windows (32 bit, 64 bit, Python version). Right now BlueBream is maintaining a list here: http://wiki.zope.org/bluebream/StatusOfWindowsBinaryPackages * Please update the ZTK documentation about the status of the ZTK steering group and the ZTK release team. It's unclear to newcomers such as myself. * In general it'd be useful if the release team recorded decisions in the ZTK documentation. It's confusing to have to go look for them in mailing list archives and people tend to forget or reinterpret decisions as time goes by. 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] Hanno, please update the ZTK
On Mon, May 3, 2010 at 13:22, Martijn Faassen faas...@startifact.com wrote: Wichert Akkerman wrote: Sorry, my mistake. I meant the ZTK release manage group, not the now defunct ZTK steering group, Well, if it's defunct or not is up to the members of the steering group. The steering group created itself, and may disband itself if it so wishes. It has all the right in the world to continue existing, even if the idea is that the ZTK oversight will be done by the release manager team instead. If it's defunct someone better update the documentation. The creation of the release manager team was only recently concluded. To expect zope process documentation to update quickly is unrealistic. -- 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] summary of suggestions
Hi Martijn, On Mon, May 3, 2010 at 2:03 PM, Martijn Faassen faas...@startifact.com wrote: Because my suggestions (besides the fork issue) as a ZTK user/contributor were scattered through the thread, here's a handy summary: Thank you very much for your suggestions. I'm sure the release team will pick these up, once we get to start actual discussions. We have only started talking to each other last week and are slowly bootstrapping. Please don't expect us to solve everything in a matter of days. 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] Hanno, please update the ZTK
Lennart Regebro wrote: On Mon, May 3, 2010 at 13:22, Martijn Faassen faas...@startifact.com wrote: Wichert Akkerman wrote: Sorry, my mistake. I meant the ZTK release manage group, not the now defunct ZTK steering group, Well, if it's defunct or not is up to the members of the steering group. The steering group created itself, and may disband itself if it so wishes. It has all the right in the world to continue existing, even if the idea is that the ZTK oversight will be done by the release manager team instead. If it's defunct someone better update the documentation. The creation of the release manager team was only recently concluded. Two weeks ago. Process started a month ago. To expect zope process documentation to update quickly is unrealistic. Well, I'm disappointed in the zope documentation process then. Work faster! If you don't inform people about this release manager team thingy, you can't rightly expect people like me to care about it. 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] summary of suggestions
Hanno Schlichting wrote: Hi Martijn, On Mon, May 3, 2010 at 2:03 PM, Martijn Faassen faas...@startifact.com wrote: Because my suggestions (besides the fork issue) as a ZTK user/contributor were scattered through the thread, here's a handy summary: Thank you very much for your suggestions. I'm sure the release team will pick these up, once we get to start actual discussions. We have only started talking to each other last week and are slowly bootstrapping. Please don't expect us to solve everything in a matter of days. Why not? Why can't you solve things in a matter of days? The fork took 5 minutes. Does it really take more than saying, okay, we're going to unfork, a few modifications to a buildout.cfg and figuring out a couple of test failures? I know it's hard to admit a mistake, but heck, it shouldn't have to take 4 months. 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] Hanno, please update the ZTK
On 5/3/10 15:41 , Martijn Faassen wrote: Lennart Regebro wrote: On Mon, May 3, 2010 at 13:22, Martijn Faassenfaas...@startifact.com wrote: Wichert Akkerman wrote: Sorry, my mistake. I meant the ZTK release manage group, not the now defunct ZTK steering group, Well, if it's defunct or not is up to the members of the steering group. The steering group created itself, and may disband itself if it so wishes. It has all the right in the world to continue existing, even if the idea is that the ZTK oversight will be done by the release manager team instead. If it's defunct someone better update the documentation. The creation of the release manager team was only recently concluded. Two weeks ago. Process started a month ago. If we're going to make cheap shots: that's still a lot faster than the grok release cycle. 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] Hanno, please update the ZTK
On 2010-05-03, Wichert Akkerman wich...@wiggy.net wrote: On 5/3/10 15:41 , Martijn Faassen wrote: Lennart Regebro wrote: On Mon, May 3, 2010 at 13:22, Martijn Faassenfaas...@startifact.com wrote: Wichert Akkerman wrote: If we're going to make cheap shots: that's still a lot faster than the grok release cycle. Guys, please, this is like watching your parents fight ;-) Can't we all just get along? :-) As someone looking in from the outside (Plone), and hoping to become more active in the Zope community in the future, I wonder what it's going to take to restore some harmony and direction in here? It seems like I've been reading various flames for months now. To put things in perspective, for folks in here who may be too close to it, the Zope ecosystem is *really* starting to shape up IMO (i.e. leaving the Zope 3 confusion in the past, etc.). I think I understand it now (after years of study), and can actually explain it to others! So let's try to keep up the *great* work and let the little things slide… 2cents, Alex 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 ) -- Alex Clark · http://aclark.net Author of Plone 3.3 Site Administration · http://aclark.net/plone-site-admin ___ 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] Hanno, please update the ZTK
On Mon, May 3, 2010 at 15:41, Martijn Faassen faas...@startifact.com wrote: Well, I'm disappointed in the zope documentation process then. Work faster! :) If you don't inform people about this release manager team thingy, you can't rightly expect people like me to care about it. Heh. Martijn, I understand you are just shaking off all the shit that you had to take, but I'm not sure everyone gets the joke. -- 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] Hanno, please update the ZTK
Lennart Regebro wrote: On Mon, May 3, 2010 at 15:41, Martijn Faassen faas...@startifact.com wrote: Well, I'm disappointed in the zope documentation process then. Work faster! :) If you don't inform people about this release manager team thingy, you can't rightly expect people like me to care about it. Heh. Martijn, I understand you are just shaking off all the shit that you had to take, but I'm not sure everyone gets the joke. That's because it's not a joke. It's because I'm pissed off. Answers like read the mailing list archives and we're working on it are legitimate sometimes. But they're also all too easily the answers of a bureaucracy that's stalling things as bureaucracies do. They're not very useful in a constructive discussion. 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] Hanno, please update the ZTK
On Mon, May 3, 2010 at 17:30, Martijn Faassen faas...@startifact.com wrote: Answers like read the mailing list archives and we're working on it are legitimate sometimes. But they're also all too easily the answers of a bureaucracy that's stalling things as bureaucracies do. They're not very useful in a constructive discussion. But in this case it's not bureaucracy that's stalling. It's the community readjusting to a large extent to fill the hole that appeared when you stepped aside. And that readjustment will NOT take a couple of days, it will take longer. We will need to keep the ZTK up to date, and I know people are committed to the ZTK so it will be. But we'll need to figure out the process, but that process isn't really done yet, and it's hard to document what doesn't exist. I don't know anything about the fork, but my view of the fork is that of Hanno wants a fork, Hanno can have a fork, as long as he doesn't try to poke anyones eye out with it. If it's a stupid waste of time, it's Hannos stupid waste of time. -- 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] Hanno, please update the ZTK
Hi there, On Mon, May 3, 2010 at 6:06 PM, Lennart Regebro rege...@gmail.com wrote: I don't know anything about the fork, but my view of the fork is that of Hanno wants a fork, Hanno can have a fork, as long as he doesn't try to poke anyones eye out with it. If it's a stupid waste of time, it's Hannos stupid waste of time. Hanno is making releases of packages in the ZTK. So it's not just Hanno's waste of time; it's mine too. That's where I was coming from when this discussion started. It didn't help that the action of making the fork really hurt me at the time - I'm not inclined to be calm about it. 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] Hanno, please update the ZTK
On 4 May 2010 00:09, Martijn Faassen faas...@startifact.com wrote: Hanno is making releases of packages in the ZTK. So it's not just Hanno's waste of time; it's mine too. That's where I was coming from when this discussion started. It didn't help that the action of making the fork really hurt me at the time - I'm not inclined to be calm about it. Unfortunately, that probably means you're going to be ignored. I'm not saying that to spite you. It's a dispassionate evaluation of what's going on right now. If I could, I'd try to get you, Hanno, Lennart, Chris McDonough and a large amount of beer in the same room. I don't think this is going to get anywhere by email. I don't think anyone even knows what this really is. Martin ___ 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] summary of suggestions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Hanno Schlichting wrote: Hi Martijn, On Mon, May 3, 2010 at 2:03 PM, Martijn Faassen faas...@startifact.com wrote: Because my suggestions (besides the fork issue) as a ZTK user/contributor were scattered through the thread, here's a handy summary: Thank you very much for your suggestions. I'm sure the release team will pick these up, once we get to start actual discussions. We have only started talking to each other last week and are slowly bootstrapping. Please don't expect us to solve everything in a matter of days. Why not? Why can't you solve things in a matter of days? The fork took 5 minutes. Does it really take more than saying, okay, we're going to unfork, a few modifications to a buildout.cfg and figuring out a couple of test failures? I know it's hard to admit a mistake, but heck, it shouldn't have to take 4 months. One issue with insta-updates to ztk.cfg is that ongoing development of a package can be in real tension with the needs of ZTK consumers for stability in the package set. E.g., I have updated zope.testbrowser/trunk to use the new version of mechanize, but don't know whether pulling that version into the ZTK proper is reasonable (in fact, I decided to have the ZTK development buildout use a stable branch for the meanwhile). If you are a ZTK consumer, and would like to see the ZTK include a newer version of one of its packages, then that need has to be balanced with the needs of the downstream projects. In effect, the new release manager group is supposed to represent the interests of Grok, Zope2, and BlueBream in a shared definition of the ZTK known good set. Getting that nailed down into a version which works for all three is *way* more important than picking up individual package changes. Once a ZTK 1.0 release is out and frozen, then we can look at opening up the trunk to more rapid breakage^Wimprovements. 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 iEYEARECAAYFAkvfCngACgkQ+gerLs4ltQ6cJACgvfiYwQMFmjqiDT94uBgiWGqM 2zwAn36lr737tui7YtiYCWDQowKpsqoB =MZu1 -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] Hanno, please update the ZTK
On Mon, May 3, 2010 at 18:09, Martijn Faassen faas...@startifact.com wrote: Hanno is making releases of packages in the ZTK. So it's not just Hanno's waste of time; it's mine too. Obviously he shouldn't hurt the main ZTK in any way. That would be a problem (even if i missed this incident completely and hence dn't understand what or how things broke). But I think the fork in itself is a red herring. -- 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] Hanno, please update the ZTK
Hi there, On Mon, May 3, 2010 at 7:48 PM, Lennart Regebro rege...@gmail.com wrote: On Mon, May 3, 2010 at 18:09, Martijn Faassen faas...@startifact.com wrote: Hanno is making releases of packages in the ZTK. So it's not just Hanno's waste of time; it's mine too. Obviously he shouldn't hurt the main ZTK in any way. That would be a problem (even if i missed this incident completely and hence dn't understand what or how things broke). But I think the fork in itself is a red herring. I spent months trying to get everybody together and there was a fork because we had a disagreement in december. Instead of working together and working with me, people just forked. That really hurt. With that lack of commitment to the ZTK, I didn't feel inclined to be committed to it either. I haven't seen a plausible reason why the fork should be necessary. It just uses some updated versions of packages (mostly bugfix releases) that would have been updated in the ZTK as well if people had bothered to update them. 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] Zope Tests: 10 OK, 4 Failed, 2 Unknown
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Test failures - Subject: FAILED: Repository policy check found errors in 670 projects From: ct at gocept.com Date: Sun May 2 21:17:48 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-May/014232.html Expected breakage. Subject: FAILED : ZTK 1.0dev / Python2.4.6 Linux 32bit From: ccomb at free.fr Date: Mon May 3 00:04:42 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-May/014243.html Breakage in the following packages, but only on Python 2.4, and only in doctests: - - zope.browserpage - - zope.viewlet - - zope.contentprovider - - zope.deferredimport At least the first one is due to doctests not exposing an '__file__' in their faux-module globals under 2.4. We might need to add Lennart's monkeypatch under 2.4, or else drop 2.4 support altogether. snip KGS 3.4.1 failures Subject: UNKNOWN : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Sun May 2 21:32:41 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-May/014235.html Subject: UNKNOWN : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Sun May 2 21:34:41 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-May/014236.html These two are my bad: I broke the 2.12 branch by backporting a fix badly from the trunk. They should run fine tonight. 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 iEYEARECAAYFAkvfD8UACgkQ+gerLs4ltQ6qjACfWkupVd3mvHfmdqaZDGLs9JnV mBoAoKnT9k9dAhj4jwvmDcL+eqpmbqe3 =1fOA -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] Hanno, please update the ZTK
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: On Mon, May 3, 2010 at 7:48 PM, Lennart Regebro rege...@gmail.com wrote: On Mon, May 3, 2010 at 18:09, Martijn Faassen faas...@startifact.com wrote: Hanno is making releases of packages in the ZTK. So it's not just Hanno's waste of time; it's mine too. Obviously he shouldn't hurt the main ZTK in any way. That would be a problem (even if i missed this incident completely and hence dn't understand what or how things broke). But I think the fork in itself is a red herring. I spent months trying to get everybody together and there was a fork because we had a disagreement in december. Instead of working together and working with me, people just forked. That really hurt. With that lack of commitment to the ZTK, I didn't feel inclined to be committed to it either. I expect to see Zope2 trunk move to using the ZTK versions list quite soon: more than that, I'm willing to to the work to see that it happens (verifying that everything passes / works with the change), and give Hanno the patch to make it so, assuming he doesn't get around to it. I haven't seen a plausible reason why the fork should be necessary. It just uses some updated versions of packages (mostly bugfix releases) that would have been updated in the ZTK as well if people had bothered to update them. If the release manager group gets consensus quickly on how their projects' interests align in the ZTK, then the fork can go away. Until then, pushing changes into the ZTK without consulting those projects' needs is premature. 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 iEYEARECAAYFAkvfEdsACgkQ+gerLs4ltQ5lIACgwyWGEHhFRXfBVng1peqKGlVJ vbIAoLiuAo2sgmT7WxgjuEoNy9mbOBz2 =EMgZ -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] summary of suggestions
Hi there, Tres Seaver wrote: One issue with insta-updates to ztk.cfg is that ongoing development of a package can be in real tension with the needs of ZTK consumers for stability in the package set. Since there are no ZTK releases Grok and BlueBream gain stability by pinning to a particular revision of ztk.cfg (and moving it forward when needed). Zope 2 could easily do the same. If more is needed, then a branch or tag can easily be made. Besides the perennial documentation issues, I also don't see why we couldn't just start releasing the ZTK; instead of pinning to an SVN revision we'd start pinning to an SVN tag (or a release URL with version number in it). What's the holdup, really? One objection I can see is that we might end up with quite a few releases in a short period, and it might be nicer to have a more stable base that people can build on. But they could simply pin to one release and stick with it for a while, right? E.g., I have updated zope.testbrowser/trunk to use the new version of mechanize, but don't know whether pulling that version into the ZTK proper is reasonable (in fact, I decided to have the ZTK development buildout use a stable branch for the meanwhile). Why wouldn't it be reasonable to try at least? If you tested it with the ZTK, you might find issues with your integration of a new version of mechanize. But anyway, you didn't release zope.testbrowser either yet, so this isn't a very good example of what I'm complaining about. I understand that you sometimes want to be careful about what to include, but this kind of ZTK-breaking release is very rare and I haven't seen a good example of it in Zope 2's list. Is there? If you are a ZTK consumer, and would like to see the ZTK include a newer version of one of its packages, then that need has to be balanced with the needs of the downstream projects. In effect, the new release manager group is supposed to represent the interests of Grok, Zope2, and BlueBream in a shared definition of the ZTK known good set. Getting that nailed down into a version which works for all three is *way* more important than picking up individual package changes. I'll note that Zope 2's fork is moving *faster* than the ZTK itself right now; a whole slew of mostly bugfix versions are used by Zope 2's list that aren't in the ZTK. I don't see a reason why instead the ZTK couldn't have been updated with those bugfix releases and Zope 2 could've used that. That way Grok and BlueBream would have benefited from the same fixes. And if Zope 2 needs to do a bigger change of a package that's in the ZTK, that might break other users of the ZTK, and do a release without discussing it here, then there is something wrong already. Anyway, this all has nothing to do with why the fork happened in december. The fork happened in december because of a very specific debate that has nothing to do with this. Such lack of commitment made me less interested in committing my own time and energy as well. 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] Hanno, please update the ZTK
Am 03.05.2010, 19:59 Uhr, schrieb Martijn Faassen faas...@startifact.com: I haven't seen a plausible reason why the fork should be necessary. It just uses some updated versions of packages (mostly bugfix releases) that would have been updated in the ZTK as well if people had bothered to update them. Maartijn, I think that most people on this list are very aware of the work you have put into Zope and particularly your dedicated refactoring of the ZTK last year. It is, unfortunately, only too common on volunteer projects that people burn out or get frustrated when things do not go their way (for whatever reason). I do not recall all the discussions that led to your resignation in December and I'm not about to trawl through all the threads for it either. But I don't understand much of today's thread that seems technically vague but personally specific. FWIW this is a very poor strategy to win people over to your point of view. You have not succeeded in making me aware of: 1) the issue and 2) a possible solution. Additionally to suggest that there has been no progress in this area over the last couple of months seems contrary to the facts. You have obviously a big, and possibly very justified, itch to scratch. Is it possible to present it less acrimoniously? If you succeed in monopolising the conversation we will be back where started. Respectfully, Charlie -- Charlie Clark Managing Director Clark Consulting Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] Hanno, please update the ZTK
Hey, Tres Seaver wrote: [snip] I expect to see Zope2 trunk move to using the ZTK versions list quite soon: more than that, I'm willing to to the work to see that it happens (verifying that everything passes / works with the change), and give Hanno the patch to make it so, assuming he doesn't get around to it. Cool. That's good to hear and something I really need to hear. :) I think you'll mostly be giving the ztk.cfg a patch to make it so, as Zope 2's list is ahead with a lot of mostly bugfix versions. I haven't seen a plausible reason why the fork should be necessary. It just uses some updated versions of packages (mostly bugfix releases) that would have been updated in the ZTK as well if people had bothered to update them. If the release manager group gets consensus quickly on how their projects' interests align in the ZTK, then the fork can go away. Until then, pushing changes into the ZTK without consulting those projects' needs is premature. Yes, such a change without such consultation was what created the problem in december. But that was a structural change of definition -- what is *in* the ZTK, not one of which releases were in the ZTK. It had something to do with letting the last zope.app.* dependency go from the cluster of zope.* packages. I'll note a short version list is not needed in order to feel that you're shrinking dependencies. I've been using depgraph for that. I will admit though that the longer the version list that is tested, the slower the tests and buildout run, of course, so that may be a concern for some (but how heavy should it weigh?). Could be something for the release managers to flesh out the balance between things. We haven't had the opportunity to have conflicts about specific releases yet (I want zope.interface 4.3! no! 4.5!). I think it's not a very big issue until someone starts doing a big dependency refactoring again - but that again is a structural issue, not a version issue. 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] Zope Tests: 10 OK, 4 Failed, 2 Unknown
Am 03.05.2010, 20:06 Uhr, schrieb Hanno Schlichting ha...@hannosch.eu: Hhm. I'm inclined to drop 2.4 support here. Using a zope.testing that tries to be compatible all the way from 2.4 to 3.1 is quite a bit of a stretch. +1 Python 2.4 itself is on life-support only*. I know it's an abrupt change for anyone coming from the Zope 2 world but that's largely because we were so slow in making the change ourselves. Charlie * I am actually aware of several commercial Python deployments that run only on 2.1 and they have all kinds of problems of their own. -- Charlie Clark Managing Director Clark Consulting Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] summary of suggestions
On Mon, May 3, 2010 at 20:13, Martijn Faassen faas...@startifact.com wrote: Since there are no ZTK releases Grok and BlueBream gain stability by pinning to a particular revision of ztk.cfg (and moving it forward when needed). Zope 2 could easily do the same. If more is needed, then a branch or tag can easily be made. Besides the perennial documentation issues, I also don't see why we couldn't just start releasing the ZTK; instead of pinning to an SVN revision we'd start pinning to an SVN tag (or a release URL with version number in it). What's the holdup, really? Making a ZTK 1.0a seems to be a good idea to me, and should help here. And we don't have to commit to anything, since it's an alpha. We could even call it 0.1, if so desired. :) One objection I can see is that we might end up with quite a few releases in a short period, and it might be nicer to have a more stable base that people can build on. But they could simply pin to one release and stick with it for a while, right? Right. -- 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] Zope Tests: 10 OK, 4 Failed, 2 Unknown
On Mon, May 3, 2010 at 20:02, Tres Seaver tsea...@palladion.com wrote: At least the first one is due to doctests not exposing an '__file__' in their faux-module globals under 2.4. We might need to add Lennart's monkeypatch under 2.4, or else drop 2.4 support altogether. Well, I don't want a monkey-patch product just for 2.4, and the monkeypatches was voted off from zope.testing because they are evil in the first place. The tests might pass __file__ in explicitly, maybe? Otherwise dropping 2.4 is probably the only reasonable option. -- 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] Hanno, please update the ZTK
Charlie Clark wrote: FWIW this is a very poor strategy to win people over to your point of view. I'm not trying to win over people to my point of view. I tried that last year, but people just forked when they couldn't work it out with me. I've learned that rash actions without consideration is the favorite method to accomplish things, so I'm trying me some of that to see whether that works better. You have not succeeded in making me aware of: 1) the issue and 2) a possible solution. The ZTK consists of a list that says which packages work together. So it's a list like: zope.component = 3.4 zope.interface = 3.7 zope.container = 3.10 The ZTK also has test infrastructure. So when (or even before) you release zope.container 3.11, you can easily run all the tests of all the packages in the ZTK and see whether anything breaks with your changes. The list of ZTK packages is used (at least subsets of this list) by Grok, BlueBream and, until december, Zope 2. Last december Hanno made progress on the ZTK's dependency structure, removing a lot of dependencies on packages. In his enthusiasm, he unilaterally just removed all those suddenly-unneeded (by him!) packages from the ZTK, without discussion. The version information was just gone. I wasn't happy that, both in my capacity as a Grok developer and in my capacity of someone honestly trying to balance the interests of parties using the ZTK. I knew those packages needed to be tested at least for Grok for a while longer. (and BlueBream too, but that didn't exist yet. We had a Zope 3 in limbo then). So I objected to this sudden removal, and went and restored the information that Hanno removed until we could discuss the right course of action. This reversion greatly upset the Zope 2 developers and they decided, an hour later, to fork the ZTK and maintain their own list of versions. We were in the middle of a discussion that was about a lot of stuff, but also included constructive attempts by me to try to resolve the situation so we could continue to work together. There was no real reason to do so - Zope 2 could've continued to use the longer version list just fine without technical problems (Grok does the same right now). But as soon as the unneeded packages weren't needed anymore by Zope 2, they wanted to stop caring about them at that very moment. I drew the consequences and a while later stepped down as ZTK steering group member. We've been in this situation ever since. It wouldn't have bothered me so much, except that people make releases. So, Zope 2 people release packages that are also in the ZTK and update their own version list and not the ZTK. They don't run the ZTK tests against their new releases. They leave it up to the ZTK maintainers to do those updates and run the ZTK's tests. This is rather annoying. The lists are needlessly out of sync. Additionally to suggest that there has been no progress in this area over the last couple of months seems contrary to the facts. You have obviously a big, and possibly very justified, itch to scratch. Is it possible to present it less acrimoniously? If you succeed in monopolising the conversation we will be back where started. No, I cannot present it less acrimoniously. The lack of commitment and trust displayed back then still hurts me too much for that. 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] summary of suggestions
Lennart Regebro wrote: On Mon, May 3, 2010 at 20:13, Martijn Faassen faas...@startifact.com wrote: Since there are no ZTK releases Grok and BlueBream gain stability by pinning to a particular revision of ztk.cfg (and moving it forward when needed). Zope 2 could easily do the same. If more is needed, then a branch or tag can easily be made. Besides the perennial documentation issues, I also don't see why we couldn't just start releasing the ZTK; instead of pinning to an SVN revision we'd start pinning to an SVN tag (or a release URL with version number in it). What's the holdup, really? Making a ZTK 1.0a seems to be a good idea to me, and should help here. And we don't have to commit to anything, since it's an alpha. I think the list needs to commit to something, because we do have people coming from older versions of Grok, BlueBream (in the form of Zope 3) and Zope 2 (though apparently Zope 2 has the least issues). While the ZTK might be new the underlying codebase isn't new at 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] Hanno, please update the ZTK
On Mon, May 3, 2010 at 9:56 PM, Martijn Faassen faas...@startifact.com wrote: Last december Hanno made progress on the ZTK's dependency structure, removing a lot of dependencies on packages. In his enthusiasm, he unilaterally just removed all those suddenly-unneeded (by him!) packages from the ZTK, without discussion. My actions last December had an unfortunate effect. I assumed a common understanding of what the ZTK should be and tried to work towards that, but it turned out that understanding wasn't shared after all. I should have known better and discussed things before taking any actions. For not discussing things properly I apologize. In didn't see any chance of making any progress during the heated debate following those events, so I decided to let things cool off and let everyone work on their own for a while. No, I cannot present it less acrimoniously. The lack of commitment and trust displayed back then still hurts me too much for that. Martijn and me tried to discuss this off-list. I think at this stage there's no way to solve our disagreement. I'd rather not continue any of this in public, as I don't see how this would have any constructive effect. The Zope community asked Christophe, Jan-Wijbrand and me to act as a release team for the ZTK and we started working on this task. I intend to continue to work in this group. If the Zope community feels I'm not qualified for the job or the other two team members don't want to work with me, I'll happily step down. 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] summary of suggestions
On Mon, May 3, 2010 at 21:57, Martijn Faassen faas...@startifact.com wrote: I think the list needs to commit to something If it needs to commit to what packages are included, then there is no reason to call it an alpha, and also, we can't do it now. So then the status persists with the users of ZTK having to use trunk, which means we can't just change versions all the time. -- 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 )
[Zope-dev] ztk checknew script
Vincent Fretin a écrit : On Sun, May 2, 2010 at 10:52 PM, Martijn Faassen faas...@startifact.com wrote: Hi there, Of course what applies to Hanno should apply to others making releases of packages maintained by the Zope Toolkit project as well. I think the ZTK leadership should figure out some kind of guidelines for this that people can follow. Maybe someone can write a tool too to check up how far a toolkit is out of sync with the latest releases. Just some ideas. For the tool, I think I did it already. I modified one of Hanno's script some times ago: cd zopetoolkit/trunk bin/buildout -c checknew.cfg bin/python checknew.py I have already started to turn this script into a buildout recipe (probably z3c.recipe.checknew). I will make sure it can discover either minor bugfix versions or major versions, and be able to create a versions.cfg. Christophe Vincent ___ 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] Hanno, please update the ZTK
Hi there, On Mon, May 3, 2010 at 10:26 PM, Hanno Schlichting ha...@hannosch.eu wrote: On Mon, May 3, 2010 at 9:56 PM, Martijn Faassen faas...@startifact.com wrote: Last december Hanno made progress on the ZTK's dependency structure, removing a lot of dependencies on packages. In his enthusiasm, he unilaterally just removed all those suddenly-unneeded (by him!) packages from the ZTK, without discussion. My actions last December had an unfortunate effect. I assumed a common understanding of what the ZTK should be and tried to work towards that, but it turned out that understanding wasn't shared after all. I should have known better and discussed things before taking any actions. For not discussing things properly I apologize. Okay, apology accepted, but we already discussed this anyway privately back in december. I apologized for the revert instead of working out the better plan that I came up with a few hours later. In my defense, I was thinking on my feet and we were still touching zope app packages that needed to be testable, so I didn't want the situation where testing this was not possible with the ZTK to linger. I also thought that I was supposed to maintain the process we had in place for removing packages and this was a bold violation of it, compounded by people arguing *I* had the burden of proof after this fait accomplit. I wish there were more steering group members involved at the time, but I couldn't really help that. In didn't see any chance of making any progress during the heated debate following those events, so I decided to let things cool off and let everyone work on their own for a while. We were making progress in that debate, and actually pretty rapidly, though it was hard to do amongst all the heat. To me, your walking out raised the immediate heat level (though I tried to ignore it), and made it completely impossible for me to cool off, as this signaled an end to collaboration and a lack of trust in me. I tried to cool off for 4 months, but today I still found myself upset about it, so that obviously wasn't working very well. No, I cannot present it less acrimoniously. The lack of commitment and trust displayed back then still hurts me too much for that. Martijn and me tried to discuss this off-list. I think at this stage there's no way to solve our disagreement. I'd rather not continue any of this in public, as I don't see how this would have any constructive effect. I don't know, perhaps you'll get me more engaged again. I'm in the situation that I have to work with people here, I want to work with people here, but my trust in my ability to work with people here was seriously damaged. Maybe that gets me out of my dilemma. The Zope community asked Christophe, Jan-Wijbrand and me to act as a release team for the ZTK and we started working on this task. I intend to continue to work in this group. If the Zope community feels I'm not qualified for the job or the other two team members don't want to work with me, I'll happily step down. I think you're qualified for the job and I trust you'll do a good one. I just hope you'll get more trust and credit than I got in december. 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] summary of suggestions
Thanks for these suggestions. This is *exactly* what we (the ztk release team) need. Are there other recommendations from other people? Martijn Faassen a écrit : Hi there, Because my suggestions (besides the fork issue) as a ZTK user/contributor were scattered through the thread, here's a handy summary: * please construct guidelines for updating the ZTK when making a release of a package that's managed by the ZTK project. It's useful people test their changes within the ZTK. * please let these guidelines not block most updates by most people most of the time; it should be easy to update the ZTK. Gatekeepers tend to slow things down a lot, and we don't have them for most Python code. We have already started discussing about this. One idea is to let the ZTK update or even release by itself, with the help of the buildbot infrastructure. I would like to replace the expected ztk bureaucracy with automated scripts that enforce some rules and *help* people. Particularly the implicit rules that make people upset when they are not respected. One example is the first message of the previous thread ;) The Zope ecosystem and its processes has become quite complex, and we cannot expect people to never do errors or to know or read everything. * there's a 'checknew.py' script to see whether there are releases newer than the ZTK. I'd be useful if this were integrated in the standard ZTK buildout.cfg so you just get a 'bin/checknew'. It'd also be nice if that were reusable by other toolkit projects. It's on the way. It will probably take the buildout.cfg as an argument, to allow checking different buildout files with possibly different versions. * (new idea) similarly it'd be nice if there were a script integrated that could check which binary egg releases exist for Windows (32 bit, 64 bit, Python version). Right now BlueBream is maintaining a list here: http://wiki.zope.org/bluebream/StatusOfWindowsBinaryPackages * Please update the ZTK documentation about the status of the ZTK steering group and the ZTK release team. It's unclear to newcomers such as myself. * In general it'd be useful if the release team recorded decisions in the ZTK documentation. It's confusing to have to go look for them in mailing list archives and people tend to forget or reinterpret decisions as time goes by. Ok, we will write down decisions or status somewhere. We are just starting organizing ourselves. Christophe 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] Zope Tests: 10 OK, 4 Failed, 2 Unknown
Hanno Schlichting a écrit : On Mon, May 3, 2010 at 8:02 PM, Tres Seaver tsea...@palladion.com wrote: Breakage in the following packages, but only on Python 2.4, and only in doctests: - - zope.browserpage - - zope.viewlet - - zope.contentprovider - - zope.deferredimport At least the first one is due to doctests not exposing an '__file__' in their faux-module globals under 2.4. We might need to add Lennart's monkeypatch under 2.4, or else drop 2.4 support altogether. Hhm. I'm inclined to drop 2.4 support here. Using a zope.testing that tries to be compatible all the way from 2.4 to 3.1 is quite a bit of a stretch. Unless I missed something, the ZTK was globally compatible with Python2.4 recently, wasn't it? Do we want the latest changes and Lennart's work to be part of the ZTK 1.0? If not, the svn branches used for the ZTK 1.0dev should be updated to point to a maintenance branch. (I suppose it's our job) Christophe 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 ) ___ 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] Zope Tests: 10 OK, 4 Failed, 2 Unknown
On Tue, May 4, 2010 at 12:41 AM, Christophe Combelles cc...@free.fr wrote: Hanno Schlichting a écrit : Hhm. I'm inclined to drop 2.4 support here. Using a zope.testing that tries to be compatible all the way from 2.4 to 3.1 is quite a bit of a stretch. Unless I missed something, the ZTK was globally compatible with Python2.4 recently, wasn't it? Do we want the latest changes and Lennart's work to be part of the ZTK 1.0? If not, the svn branches used for the ZTK 1.0dev should be updated to point to a maintenance branch. (I suppose it's our job) Dropping Python 2.4 supports makes most sense to me at this stage. Zope2/Plone only support Python 2.6 for any modern version. I don't know what BlueBream and Grok want to support, but would guess they aim for Python 2.5 + 2.6 support. 2.4 is really old by now. 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] summary of suggestions
Hey, Christophe Combelles wrote: Thanks for these suggestions. This is *exactly* what we (the ztk release team) need. How wonderfully diplomatic and constructive, my compliments! The release team (you, Hanno and JW) look good to me. * please let these guidelines not block most updates by most people most of the time; it should be easy to update the ZTK. Gatekeepers tend to slow things down a lot, and we don't have them for most Python code. We have already started discussing about this. One idea is to let the ZTK update or even release by itself, with the help of the buildbot infrastructure. I would like to replace the expected ztk bureaucracy with automated scripts that enforce some rules and *help* people. Particularly the implicit rules that make people upset when they are not respected. One example is the first message of the previous thread ;) The Zope ecosystem and its processes has become quite complex, and we cannot expect people to never do errors or to know or read everything. Yes. But I don't think you can replace people's judgment with processes completely. Differences of judgment will continue to exist too, and they shouldn't lead to deadlocks. In that case it becomes useful to have leadership with vision with the authority to break deadlocks. Vision is also useful to go beyond processes. I think one interesting distinction has to do with structure versus versions. I think we should be quite open in allowing people to release new versions of packages and update the ZTK. Especially bugfix releases, of course, but I think many feature releases can also be safely integrated. Structural changes, where packages are dropped or added, need more discussion. I think the cost for having a package in the ZTK is fairly low as long as it doesn't have a lot of things depending on it, but I realize that the cost is non-zero so shrinking the ZTK sounds like a good plan. Dropping is dangerous for other reasons than adding. Adding a package is dangerous as you give a certain commitment to maintain this package for a long time. Dropping a package is dangerous as you break this commitment. We have the complexity here that we have a *new* project that is actually the underpinning of several projects (Grok, BlueBream, Zope 2) with a long history. I therefore think the issue of dropping is immediately relevant, not only after the 1.0 release. Why is dropping a package an issue? It's an issue because you break backward compatibility promises. Another way to look at it is that you're removing features from the ZTK. Another way to look at it is that you're removing *tests* from the ZTK. We don't expect people to just remove a bunch of tests from zope.component without a very good reason and probably some discussion. I think this is why version updates are generally okay, even drastic version updates, and structural updates are more risky. Of course there are some cases where a version update can break a lot of other packages. I.e. the package is depended on a lot by other packages and you're changing a contract. This is a situation that should be as carefully considered as removing a package. I think the structural organization should follow the lines of interest of project groups more than it should follow lines of content. But I'm wary about trying to organize too much, as separating bits *does* make maintenance harder. * there's a 'checknew.py' script to see whether there are releases newer than the ZTK. I'd be useful if this were integrated in the standard ZTK buildout.cfg so you just get a 'bin/checknew'. It'd also be nice if that were reusable by other toolkit projects. It's on the way. It will probably take the buildout.cfg as an argument, to allow checking different buildout files with possibly different versions. Cool. Also reasonable to make 'buildout.cfg' the default, I think? * In general it'd be useful if the release team recorded decisions in the ZTK documentation. It's confusing to have to go look for them in mailing list archives and people tend to forget or reinterpret decisions as time goes by. Ok, we will write down decisions or status somewhere. We are just starting organizing ourselves. I think you can just use this: http://docs.zope.org/zopetoolkit/ That's what it is for. It's a Sphinx site. Just a few updates that Wichert can point me to when I get confused would probably help both me and Wichert tremendously. :) I kept decisions here, though they should be reorganized: http://docs.zope.org/zopetoolkit/steeringgroup/decisions.html You could probably start a new page like that. 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] summary of suggestions
Hi again, One more suggestion I can make is a way to get an integrated changelog for lists of packages such as the ZTK. Right now it's hard to track what kind of changes there have been in the ZTK as a whole; you have to go through all packages. If there were a way to generate a unified changelog between two versions of a ztk.cfg (or other such files), that would be useful in doing releases. A long time ago I experimented with a way to turn a CHANGES.txt into an atom feed and then to aggregate those feeds into a Planet in order to get some idea of what's going on. Maybe that'd be an interesting approach to this. 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] Hanno, please update the ZTK
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hanno Schlichting wrote: On Mon, May 3, 2010 at 9:56 PM, Martijn Faassen faas...@startifact.com wrote: Last december Hanno made progress on the ZTK's dependency structure, removing a lot of dependencies on packages. In his enthusiasm, he unilaterally just removed all those suddenly-unneeded (by him!) packages from the ZTK, without discussion. My actions last December had an unfortunate effect. I assumed a common understanding of what the ZTK should be and tried to work towards that, but it turned out that understanding wasn't shared after all. I should have known better and discussed things before taking any actions. For not discussing things properly I apologize. In didn't see any chance of making any progress during the heated debate following those events, so I decided to let things cool off and let everyone work on their own for a while. Could we go ahead and move the Zope2 trunk back to 'extends ztk.cfg w/ the minimal possible deltas, instead of the current keep ourselves to ourselves state? It would be even better if that meant that Grok and BlueBream would walk the tightrope with Zope2, and give up the relative safety of a pinned revision of ztk.cfg on their own trunks, sharing instead with the Zope2 trunk a white knuckle grip on the contents of zopetoolkit/trunk/ztk.cfg until we can get ZTK to a release. The Zope community asked Christophe, Jan-Wijbrand and me to act as a release team for the ZTK and we started working on this task. I intend to continue to work in this group. If the Zope community feels I'm not qualified for the job or the other two team members don't want to work with me, I'll happily step down. I believe that the three of you are ideal as representatives of the major downstream consumers of the ZTK. I hope that your triumvirate can converge quickly on a process of achieving consensus on the maximal set of shared package versions between the projects. 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 iEYEARECAAYFAkvfZKQACgkQ+gerLs4ltQ40BACdEXBzDtEKkg+GSv8mSmyybjCH N8oAnRnWnpsbUaM6Qwo5Jv3yKmSg1oi+ =P0Vc -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] Zope Tests: 10 OK, 4 Failed, 2 Unknown
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christophe Combelles wrote: Hanno Schlichting a écrit : On Mon, May 3, 2010 at 8:02 PM, Tres Seaver tsea...@palladion.com wrote: Breakage in the following packages, but only on Python 2.4, and only in doctests: - - zope.browserpage - - zope.viewlet - - zope.contentprovider - - zope.deferredimport At least the first one is due to doctests not exposing an '__file__' in their faux-module globals under 2.4. We might need to add Lennart's monkeypatch under 2.4, or else drop 2.4 support altogether. Hhm. I'm inclined to drop 2.4 support here. Using a zope.testing that tries to be compatible all the way from 2.4 to 3.1 is quite a bit of a stretch. Unless I missed something, the ZTK was globally compatible with Python2.4 recently, wasn't it? Do we want the latest changes and Lennart's work to be part of the ZTK 1.0? I recall a general consensus that we would be officially supporting Python 2.5 and 2.6, and that we wouldn't deliberately break Python 2.4 without good reason. A spacial exception was for zope.interface, zope.component, zope.configuration, and their dependencies: because they were already in much wider use outside traditional Zope projects, Python 2.4 compatibility for the bicycle seat toolkit package subset was identified as being *more* important than the ZTK as a whole: At this point, Lennart's work has been aimed at increasing forward compatibility with Python = 3.1.x: I believe that trading away 2.4.x compatibility in order to get 3.1.x compatibility is a sane choice. If not, the svn branches used for the ZTK 1.0dev should be updated to point to a maintenance branch. (I suppose it's our job) Before you go down that road, I would argue that somebody needs to speak up who actually needs the whole ZTK (and zopeapp) to run on Pythonn 2.4. In particular, this means somebody who has an existing application which *both* requires staying on Python 2.4 *and* expects to be updated to use ztk.cfg and / or zopeapp.cfg, rather than a project-specific KGS or index. Note that I believe the intersection of those two sets is very likely empty at this point. 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 iEYEARECAAYFAkvfa34ACgkQ+gerLs4ltQ7pAACfT3lbi0uf7WhIFHXn0cxJwGYE 7UIAoNpSp6sNBAUfYAnf+3e9Bf99CjTS =LCYP -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] Zope Tests: 10 OK, 4 Failed, 2 Unknown
On Tue, May 4, 2010 at 4:24 AM, Hanno Schlichting ha...@hannosch.eu wrote: Dropping Python 2.4 supports makes most sense to me at this stage. Zope2/Plone only support Python 2.6 for any modern version. I don't know what BlueBream and Grok want to support, but would guess they aim for Python 2.5 + 2.6 support. 2.4 is really old by now. Python 2.4 will be supported for BB 1.0 release, but the package versions for that release is already freezed, so no problem for dropping 2.4 support. AFAIK, Grok 1.1 release versions are also freezed as a release candidate is out. Regards, Baiju M ___ 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] SVN: Zope/trunk/versions.cfg Group versions by the 'sets' to which they correspond.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tres Seaver wrote: Log message for revision 111904: Group versions by the 'sets' to which they correspond. Changed: U Zope/trunk/versions.cfg -=- Modified: Zope/trunk/versions.cfg === --- Zope/trunk/versions.cfg 2010-05-03 17:57:11 UTC (rev 111903) +++ Zope/trunk/versions.cfg 2010-05-04 01:49:24 UTC (rev 111904) @@ -2,39 +2,26 @@ versions = versions [versions] +# Zope2-specific Zope2 = Acquisition = 2.13.3 -ClientForm = 0.2.10 DateTime = 2.12.1 -distribute = 0.6.10 -docutils = 0.6 ExtensionClass = 2.13.1 initgroups = 2.13.0 -Jinja2 = 2.3.1 -mechanize = 0.1.11 Missing = 2.13.0 MultiMapping = 2.13.0 Persistence = 2.13.1 -Pygments = 1.3.1 -python-gettext = 1.0 -pytz = 2010b Record = 2.13.0 RestrictedPython = 3.5.2 -Sphinx = 0.6.5 -setuptools= 0.6c11 tempstorage = 2.11.2 ThreadLock = 2.13.0 -tl.eggdeps = 0.4 -transaction = 1.0.0 -z3c.recipe.depgraph = 0.5 -zc.buildout = 1.4.3 -zc.lockfile = 1.0.0 -zc.recipe.egg = 1.2.2 -zc.recipe.testrunner = 1.2.0 -ZConfig = 2.8.0 -zdaemon = 2.0.4 -ZODB3 = 3.9.5 ZopeUndo = 2.12.0 + +# Zope2 dependencies +pytz = 2010b +docutils = 0.6 + +# ZTK zope.annotation = 3.5.0 zope.broken = 3.6.0 zope.browser = 1.3 @@ -75,3 +62,28 @@ zope.testing = 3.9.4 zope.traversing = 3.12.1 zope.viewlet = 3.7.1 + +# ZTK dependencies +mechanize = 0.1.11 +ClientForm = 0.2.10 + +# ZODB + dependencies +transaction = 1.0.0 +zc.lockfile = 1.0.0 +ZConfig = 2.8.0 +zdaemon = 2.0.4 +ZODB3 = 3.9.5 + +# toolchain +Jinja2 = 2.3.1 +Pygments = 1.3.1 +python-gettext = 1.0 +Sphinx = 0.6.5 +distribute = 0.6.10 +setuptools= 0.6c11 +tl.eggdeps = 0.4 +z3c.recipe.depgraph = 0.5 +zc.buildout = 1.4.3 +zc.recipe.egg = 1.2.2 +zc.recipe.testrunner = 1.2.0 + Hanno, After splitting the Zope2 package versions up this way, it gets easier to see how they interact with the ones in ztk.cfg. I'm attaching a patch which adds back the 'extends = ' line, removes the versions from the ZTK and ZTK dependencies section which match, and adds comments for the overrides. If the Grok and BlueBream folks agree, then maybe we could just land all the versions currently in Zope2's versions.cfg, and have its overrides section be (temporarily, at least) empty. 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 iEYEARECAAYFAkvfgj4ACgkQ+gerLs4ltQ7lpwCeNrOs+Pbgr7GLxw9BWnoVJZqw qsAAn0CyaT/NXlMEEK9DDTFenfdljHnZ =weCU -END PGP SIGNATURE- === modified file 'versions.cfg' --- versions.cfg 2010-05-04 01:30:19 + +++ versions.cfg 2010-05-04 02:08:13 + @@ -1,5 +1,6 @@ [buildout] versions = versions +extends = http://svn.zope.org/repos/main/zopetoolkit/trunk/ztk.cfg [versions] # Zope2-specific @@ -21,51 +22,36 @@ pytz = 2010b docutils = 0.6 -# ZTK -zope.annotation = 3.5.0 -zope.broken = 3.6.0 -zope.browser = 1.3 -zope.browsermenu = 3.9.1 -zope.browserpage = 3.12.1 -zope.browserresource = 3.10.3 -zope.component = 3.9.4 -zope.configuration = 3.7.2 -zope.container = 3.11.1 -zope.contentprovider = 3.7.1 -zope.contenttype = 3.5.1 -zope.datetime = 3.4.0 -zope.deferredimport = 3.5.1 -zope.dottedname = 3.4.6 -zope.event = 3.4.1 -zope.exceptions = 3.6.0 -zope.filerepresentation = 3.6.0 -zope.i18n = 3.7.3 -zope.i18nmessageid = 3.5.2 -zope.interface = 3.6.1 -zope.lifecycleevent = 3.6.1 -zope.location = 3.9.0 -zope.pagetemplate = 3.5.1 -zope.processlifetime = 1.0 -zope.proxy = 3.6.0 -zope.ptresource = 3.9.0 -zope.publisher = 3.12.3 -zope.schema = 3.6.3 -zope.security = 3.7.3 -zope.sendmail = 3.7.2 -zope.sequencesort = 3.4.0 -zope.site = 3.9.1 -zope.size = 3.4.1 -zope.structuredtext = 3.5.0 -zope.tal = 3.5.2 -zope.tales = 3.5.1 -zope.testbrowser = 3.8.1 -zope.testing = 3.9.4 -zope.traversing = 3.12.1 -zope.viewlet = 3.7.1 +# ZTK (only deltas from the one we extend) +zope.browser = 1.3 # ztk: 1.2 +zope.browsermenu = 3.9.1# ztk: 3.9.0 +zope.browserpage = 3.12.1 # ztk: 3.12.0 +zope.browserresource = 3.10.3 # ztk: 3.10.1 +zope.component = 3.9.4 # ztk: 3.9.4 +zope.configuration = 3.7.2 # ztk: 3.7.1 +zope.container = 3.11.1 # ztk: 3.11.0 +zope.contentprovider = 3.7.1# ztk: 3.7 +zope.deferredimport = 3.5.1 # ztk: 3.5.0 +zope.exceptions = 3.6.0 # ztk: 3.5.2 +zope.i18n = 3.7.3 # ztk: 3.7.3 +zope.i18nmessageid = 3.5.2 # ztk: 3.5.1 +zope.interface = 3.6.1 # ztk: 3.5.3 +zope.lifecycleevent = 3.6.1 # ztk: 3.6.0 +zope.pagetemplate = 3.5.1 # ztk: 3.5.0 +zope.proxy =
Re: [Zope-dev] SVN: Zope/trunk/versions.cfg Group versions by the 'sets' to which they correspond.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tres Seaver wrote: Tres Seaver wrote: Log message for revision 111904: Group versions by the 'sets' to which they correspond. Changed: U Zope/trunk/versions.cfg -=- Modified: Zope/trunk/versions.cfg === --- Zope/trunk/versions.cfg 2010-05-03 17:57:11 UTC (rev 111903) +++ Zope/trunk/versions.cfg 2010-05-04 01:49:24 UTC (rev 111904) @@ -2,39 +2,26 @@ versions = versions [versions] +# Zope2-specific Zope2 = Acquisition = 2.13.3 -ClientForm = 0.2.10 DateTime = 2.12.1 -distribute = 0.6.10 -docutils = 0.6 ExtensionClass = 2.13.1 initgroups = 2.13.0 -Jinja2 = 2.3.1 -mechanize = 0.1.11 Missing = 2.13.0 MultiMapping = 2.13.0 Persistence = 2.13.1 -Pygments = 1.3.1 -python-gettext = 1.0 -pytz = 2010b Record = 2.13.0 RestrictedPython = 3.5.2 -Sphinx = 0.6.5 -setuptools= 0.6c11 tempstorage = 2.11.2 ThreadLock = 2.13.0 -tl.eggdeps = 0.4 -transaction = 1.0.0 -z3c.recipe.depgraph = 0.5 -zc.buildout = 1.4.3 -zc.lockfile = 1.0.0 -zc.recipe.egg = 1.2.2 -zc.recipe.testrunner = 1.2.0 -ZConfig = 2.8.0 -zdaemon = 2.0.4 -ZODB3 = 3.9.5 ZopeUndo = 2.12.0 + +# Zope2 dependencies +pytz = 2010b +docutils = 0.6 + +# ZTK zope.annotation = 3.5.0 zope.broken = 3.6.0 zope.browser = 1.3 @@ -75,3 +62,28 @@ zope.testing = 3.9.4 zope.traversing = 3.12.1 zope.viewlet = 3.7.1 + +# ZTK dependencies +mechanize = 0.1.11 +ClientForm = 0.2.10 + +# ZODB + dependencies +transaction = 1.0.0 +zc.lockfile = 1.0.0 +ZConfig = 2.8.0 +zdaemon = 2.0.4 +ZODB3 = 3.9.5 + +# toolchain +Jinja2 = 2.3.1 +Pygments = 1.3.1 +python-gettext = 1.0 +Sphinx = 0.6.5 +distribute = 0.6.10 +setuptools= 0.6c11 +tl.eggdeps = 0.4 +z3c.recipe.depgraph = 0.5 +zc.buildout = 1.4.3 +zc.recipe.egg = 1.2.2 +zc.recipe.testrunner = 1.2.0 + Hanno, After splitting the Zope2 package versions up this way, it gets easier to see how they interact with the ones in ztk.cfg. I'm attaching a patch which adds back the 'extends = ' line, removes the versions from the ZTK and ZTK dependencies section which match, and adds comments for the overrides. If the Grok and BlueBream folks agree, then maybe we could just land all the versions currently in Zope2's versions.cfg, and have its overrides section be (temporarily, at least) empty. Should the triumvirs so decide, attached is the patch for zopetoolkit which adopts the versions from Zope2. The normal buildout (using eggs rather than checkouts) passes all test-ztk and test-zopeapp tests with this patch applied. 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 iEUEARECAAYFAkvfhaMACgkQ+gerLs4ltQ7nngCgxvf1leQxkvJRCCg6Z2c/QB9G EqgAmK8lQkJkYokzxaiyHUFtRyceaig= =esK4 -END PGP SIGNATURE- === modified file 'ztk.cfg' --- ztk.cfg 2010-04-28 15:43:25 + +++ ztk.cfg 2010-05-04 02:17:56 + @@ -95,71 +95,71 @@ zope.applicationcontrol = 3.5.5 zope.authentication = 3.7.0 zope.broken = 3.6.0 -zope.browser = 1.2 -zope.browsermenu = 3.9.0 -zope.browserpage = 3.12.0 -zope.browserresource = 3.10.2 +zope.browser = 1.3 +zope.browsermenu = 3.9.1 +zope.browserpage = 3.12.1 +zope.browserresource = 3.10.3 zope.cachedescriptors = 3.5.0 zope.catalog = 3.8.1 -zope.component = 3.9.3 +zope.component = 3.9.4 zope.componentvocabulary = 1.0 -zope.configuration = 3.7.1 -zope.container = 3.11.0 -zope.contentprovider = 3.7 +zope.configuration = 3.7.2 +zope.container = 3.11.1 +zope.contentprovider = 3.7.1 zope.contenttype = 3.5.1 zope.copy = 3.5.0 zope.copypastemove = 3.6.0 zope.datetime = 3.4.0 -zope.deferredimport = 3.5.0 +zope.deferredimport = 3.5.1 zope.deprecation = 3.4.0 zope.documenttemplate = 3.4.2 zope.dottedname = 3.4.6 zope.dublincore = 3.6.0 zope.error = 3.7.0 zope.event = 3.4.1 -zope.exceptions = 3.5.2 +zope.exceptions = 3.6.0 zope.file = 0.5.0 zope.filerepresentation = 3.6.0 zope.formlib = 4.0.2 zope.hookable = 3.4.1 zope.html = 2.0.0 -zope.i18n = 3.7.2 -zope.i18nmessageid = 3.5.1 +zope.i18n = 3.7.3 +zope.i18nmessageid = 3.5.2 zope.index = 3.6.0 -zope.interface = 3.5.3 +zope.interface = 3.6.1 zope.intid = 3.7.2 zope.keyreference = 3.6.2 -zope.lifecycleevent = 3.6.0 +zope.lifecycleevent = 3.6.1 zope.location = 3.9.0 zope.login = 1.0.0 zope.mimetype = 1.2.0 zope.minmax = 1.1.2 -zope.pagetemplate = 3.5.0 +zope.pagetemplate = 3.5.1 zope.password = 3.5.1 zope.pluggableauth = 1.0.1 zope.principalannotation = 3.6.0 zope.principalregistry = 3.7.0 zope.processlifetime = 1.0 -zope.proxy = 3.5.0 +zope.proxy = 3.6.0 zope.ptresource = 3.9.0 -zope.publisher = 3.12.2 +zope.publisher = 3.12.3 zope.ramcache = 1.0
