[Zope-dev] Summary of today's developer meeting
Hi, here's the summary of yesterday's meeting. The meeting itself was going more in-depth on the topic we covered so for the next meeting I'll make the agenda even shorter. On the experiment side: while writing up the summary I noticed that yesterday's discussions started going into different directions at the same time and jump around without necessarily having conclusions. That makes it *very* hard to write summaries. I guess I'll try to moderate a bit better next week. I'm not sure what was different this week from last. Any ideas? Christian -- Christian Theune · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development = Weekly Zope developer meeting = This is the summary of the weekly Zope developer meeting which happened on Tuesday, 2010-03-09 on #z...@irc.freenode.org from 3pm to 3:30pm (UTC). The agenda for this meeting is available in the mailing list archives: https://mail.zope.org/pipermail/zope-dev/2010-March/039769.html The IRC logs are located here: http://zope3.pov.lt/irclogs-zope Volunteer for automated build/nightly test coordination === We are still looking for a volunteer to coordinate the automated build efforts. mgedmin wasn't present but in one of his recent blog entries he expressed that he thinks not being a good fit for that task. We continue looking for a volunteer. (Update: I was personally contacted by Patrick Gerken who volunteered. I will follow up on this with him.) Improving visibility and coverage of (expected) test runs == (Note from writing the summary: The discussion of this topic was hard to put into a coherent structure for the summary. I guess we need to watch out in the future to keep discussions during the meeting time a bit more focused on a single thread of conversation and have explicit agreement when switching topics. So the following summary is somewhat murky, too.) - One of the shortcomings in our automated testing infrastructure is that we lack a clear and up-to-date view of what tests we should be running and verifying whether we do so or not. - Producing that list isn't directly straight forward. Ensuring that the tests of all toolkits are run is a good first step. We need to go further so and we need this list to be either manageable very easily or (better?) produced automatically by looking at the repository. - The zope-tests aggregator is already in place and functions well to remind the developer about undesirable situations. This could be used for all kinds of reminders, not just broken builds, but also missing builds, offline buildsbots ... we just have to write some utility code that checks for those things. (Think of a Nagios for developers.) - One action for the automatic build coordinator would be to get all buildbot admins to send compatible email to the zope-tests mailing list. Improving the reliability of making Windows builds available On the topic of having Windows builds available regularly and reliably we discussed that there is a need to have a list of packages (with version/platform/python) combinations that require binary eggs so we can both trigger builds for those packages on the appropriate platforms or have at least alerts if we miss builds. Note: people went on a while after the official meeting time discussing the use of Amazon EC 2 for Windows machines with Visual Studio licenses. The idea arose that the ZF should be approach about sponsoring this setup (and maybe in turn get sponsorship by MS for the compiler suite). Sidnei da Silva volunteered (with Hanno Schlichting helping) to approach this by producing an AMI which can be run by anyone. He will work on a relaxed schedule as both Hanno and Sidnei are busy and there are other topics WRT automated builds and testing that make sense to be completed first. Martijn already posted a request to the ZF to ponder the financing and contacting MS for sponsorship which Tres' already picked up. Post-poned and new issues = The following agenda items did not make it within the time limit: - Towards a ZTK release - What is needed for a release? - Who's the release manager? - Can we ensure building Windows binaries? - Bug tracking/working on bugs regularly - How do we deal with proposed API changes and Python 3 compatibility? (Lennart Regebro) - Chris McDonough suggests to ponder further structuring of the ZTK into separate sub-sets which might allow us to get better mileage regarding maintenance and release management. He gave the example of the Bicycle Toolkit (zope.component, zope.configuration, zope.interface).
[Zope-dev] Zope Tests: 6 OK
Summary of messages to the zope-tests list. Period Tue Mar 9 12:00:00 2010 UTC to Wed Mar 10 12:00:00 2010 UTC. There were 6 messages: 6 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Tue Mar 9 20:36:32 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013708.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Tue Mar 9 20:38:32 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013709.html Subject: OK : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Tue Mar 9 20:40:32 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013710.html Subject: OK : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Tue Mar 9 20:42:32 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013711.html Subject: OK : Zope-trunk Python-2.6.4 : Linux From: Zope Tests Date: Tue Mar 9 20:44:32 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013712.html Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux From: Zope Tests Date: Tue Mar 9 20:46:32 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013713.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 )
Re: [Zope-dev] Optional C extensions
On Tue, Mar 9, 2010 at 6:15 PM, Tim Hoffman zutes...@gmail.com wrote: Hi As Attila pointed out, zope.proxy is possible to implement using peak.util.proxies if you only want some limited zope.proxy support. You won't get zope.security going down this path. I do that specifically so that I can use zope.deferredimport on app engine. Below is the awful hacking I do to zope.proxy.__init__ to make it support zope.deferredimport on appengine. Please don't encourage this. People reading this, please forget you read Tim's email. :) (Jim whips out special pen and asks that everyone look in his direction for a moement.) zope.deferred import should, perhaps, be modified to use peak.util.proxies, but we should not have packages floating around that modify zope.proxy to weaken it. I wish I had agitated to make changes to Python to make deferred imports use of zope.proxy unnecessary. Jim -- Jim Fulton ___ 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] Optional C extensions
Hi Jim Yeah I agree with you. I haven't ever distributed that version of zope.proxy , just used it internally to support deferredimport. zope.security could never to what it does with a pure python version of zope.proxy. the 'c' wrappers are very important to ensure security. Unfortunately I needed deferredimport and was completely unsure how else to proceed at the time. I use code generation for gae based models, and the unfortunately reference entities need actual models/classes which means you can very easily create cyclic dependancies. Storm allows references to be defined strings such as model.MyClass but gae doesn't implement such a thing, so deferredimport was the next best thing. T On Wed, Mar 10, 2010 at 8:05 PM, Jim Fulton j...@zope.com wrote: On Tue, Mar 9, 2010 at 6:15 PM, Tim Hoffman zutes...@gmail.com wrote: Hi As Attila pointed out, zope.proxy is possible to implement using peak.util.proxies if you only want some limited zope.proxy support. You won't get zope.security going down this path. I do that specifically so that I can use zope.deferredimport on app engine. Below is the awful hacking I do to zope.proxy.__init__ to make it support zope.deferredimport on appengine. Please don't encourage this. People reading this, please forget you read Tim's email. :) (Jim whips out special pen and asks that everyone look in his direction for a moement.) zope.deferred import should, perhaps, be modified to use peak.util.proxies, but we should not have packages floating around that modify zope.proxy to weaken it. I wish I had agitated to make changes to Python to make deferred imports use of zope.proxy unnecessary. Jim -- Jim Fulton ___ 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] Optional C extensions
On Wed, Mar 10, 2010 at 7:17 AM, Tim Hoffman zutes...@gmail.com wrote: ... Unfortunately I needed deferredimport and was completely unsure how else to proceed at the time. I use code generation for gae based models, and the unfortunately reference entities need actual models/classes which means you can very easily create cyclic dependancies. Storm allows references to be defined strings such as model.MyClass but gae doesn't implement such a thing, so deferredimport was the next best thing. I thought about this a bit and realized that I could implement deferred import without using proxies. I don't know why I didn't think of this before. Then I looked at the Importing project, which provides the peak.util.imports package: http://peak.telecommunity.com/DevCenter/Importing This looks like a good alternative to zope.deferredimport. Maybe we should deprecate zope.deferredimport in favor of Importing. If there are interesting things that depend on zope.deferredimport that we don't want to update, we could reimplement zope.deferredimport using Importing. Importing has other nice features beyond lazy importing. Personally, I'm going to start switching my uses of zope.deferredimport to use Importing. Jim -- Jim Fulton ___ 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 )
