2010-07-06

This is the agenda and summary for the weekly Zope developer meeting of Tuesday, 2010-07-06 on #zope@irc.freenode.org from 15:00 to 15:30 UTC.

Summary

The IRC log is available here:

http://zope3.pov.lt/irclogs-zope/%23zope.2010-07-06.log.html#t2010-07-06T18:00:42

Attendees

Tres Seaver, Adam Groszer, Hanno Schlichting, Charlie Clark, Wichert Akkermann, Jens Vagelpohl, d2m, davisagli

VCS properties

In a recent discussion on the CMF mailinglist the question was raised what our ruleso n using VCS properties (especially $Id$) are.

The discussion traced the origin back to CVS and generally argued that the need for the IDs does not exist anymore but actually obstruct diffs in SVN. The suggestion was to change the policy to ask for not adding properties in the future anymore and opportunistically remove IDs whenever we stumble over them.

A poll showed 7 people in favor of this action, none against it. Tres updated the ZTK documentation to reflect the decision.

Expectations for the summit

We had a round of people expressing what interest and expectations they have on topics that we might deal with at the summit. Here’s the assorted list of topics that came up:

  • more compelling stories for Zope

  • better documentation

  • developer portraits/company profiles/product use-cases on zope.org

  • opening up for experimentation and then folding together common experiences into common code (like HTML 5)

  • higher quality code versus more code

  • actively find and describe use cases

Optional C-optimisations

Some projects (like i18nmessageid) have optional C-code and in general would work on Non-CPython-platforms (GAE, Jython, IronPython, Windows) if the build process would support it. Unfortunately neither setuptools nor distributes helps with spelling optional extensions, thus Tres started working on zope.optionalextension which is intended to work together with bare distutils, setuptools and distribute.

Meta

Today we had a surprising large number of participants, compared to previous weeks with only the same three people.

A member from US West Coast reported that he has a hard time joining at the current time the meeting takes place at.

Hanno pointed out that we might want to take some topics explicitly to the mailing list if attendance is low and topics need to be driven forward. Charlie pointed out that to get to decisions real-time meetings (like IRC) may be more productive. There was no conclusion on the issue and Hanno withdrew his suggestion.

Christian Theune asked for input about managing ongoing issues, but no ideas came up.

Agenda

  • Use of $Id$ properties in code (keep, remove active, remove opportunistically) See https://mail.zope.org/pipermail/zope-cmf/2010-July/029208.html

  • Expectations for the upcoming Zope summit?

  • Meta

    • 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?)

Ongoing issues

Those issues are currently ongoing. We don’t have to discuss them. We just need to follow up on them eventually.

  • ZTK status
    • Towards a ZTK release

      • Documentation

      • Release scope

  • Test runners / nightly builds
    • Windows

      • 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

  • Documentation
    • 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)

  • Releases

    • 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?

Topic proposals

  • 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.