This is the agenda and summary for the weekly Zope developer meeting of Tuesday, 2010-07-27 on #email@example.com from 15:00 to 15:30 UTC.
- The IRC log is available here:
Leonardo Rochael, Wichert Akkerman, Jens Vagelpohl, Adam Groszer, Christian Theune
Unfortunately no EP participant was around and I’d like to encourage those who visited EP to give an update to the non-attending Zope developers on what happened from a Zope perspective. Talks? Sprints? Interesting discussions?
Christian agreed to send a mail inviting participants to write up their experience.
Review languishing bugs¶
I retried the experiment inviting the other participants for reviewing languishing bugs. Instead of the misunderstanding of last week a more in-depth discussion about expectations WRT communication via bug trackers, responsiveness, process occured. The discussion was undirected and relatively general but raised some concerns that might be good input for the upcoming summit, too. Please see the IRC log if you’re interested in the details.
- Review EuroPython
- Review languishing bugs. (See https://mail.zope.org/pipermail/zope-tests/2010-July/016049.html https://mail.zope.org/pipermail/zope-tests/2010-July/016050.html https://mail.zope.org/pipermail/zope-tests/2010-July/016051.html https://mail.zope.org/pipermail/zope-tests/2010-July/016052.html)
Those issues are currently ongoing. We don’t have to discuss them. We just need to follow up on them eventually.
- Abandoned projects (Tres)
- Expectations for the upcoming Zope summit?
- Review meeting itself, maybe add extra 15 minutes for “meta” once a month or every two months? (postponed until 2010-06-01)
- How to organize open issues in the long run (Blueprints? Other tool? Continue text files?)
- ZTK status
- Towards a ZTK release
- Release scope
- Test runners / nightly builds
- Compiler licenses (Tres, postponed until after 2010-06-14)
- Win egg builder (Adam)
- Documentation about VM setup (Adam)
- Supporting Python 2.7
- Needs help from the buildbots
- Consolidate “floating” documentation into Sphinx/docs.zope.org
- write blueprint for the consolidation effort (Theuni)
- Find candidate links and gather them centrally
- Edit/update the documentation from the link list and land in Sphinx-style during a sprint
- Turn ZTK package documentation into sphinx style (like zope.event)
- write bug and assign to toolkit projects (Theuni)
- Provide package documentation under docs.zope.org/<packagename> and keep updated based on the projects’ trunks. (Jens)
- How to find a good point when to cut a new release for a package for which fixed bugs where registered (or changes have been made)? Any automation possible to alert us when changes have been sitting around unreleased for a while?
- Chris McDonough: Pondering some (re-)structuring of the ZTK to allow for better maintenance/release management/communication/marketing.
- Christian Theune: I’d like us to ponder how we can (in addition to the housekeeping and cleanups we do) also move to do constructive work together to expand the stuff that Zope packages (ZTK) is about. How do we go about implementing new technologies together, like supporting HTML 5 in the various parts? I’d like to start putting in new code in the foreseeable future in the zope.* namespace.