============================= Weekly Zope developer meeting ============================= This is the summary of the weekly Zope developer meeting which happened on Tuesday, 2010-03-09 on #zope@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).