This is the agenda and summary for the weekly Zope developer meeting of Tuesday, 2010-10-19 on #firstname.lastname@example.org from 15:00 to 15:30 UTC.
- The IRC log is available here:
Christian Theune, Tres Seaver, Jan-Wijbrandt Kolman, Jim Fulton, Chris McDonough
- Follow-up on summit goals
- Plan next bug day
- Bicycle toolkit
Follow-up on summit goals¶
Didn’t talk much. Thomas started a thread on discussing the functional areas, but he’s sick currently.
We fixed the next bug day to Tuesday 2010-10-26. Christian promised to declare what he wants to work on in an announcement mail later today to make the bug day activities more visible.
Christian mentioned that he finds the BTK seems to overlap with the goal to define functional areas. The BTK might be one of the functional areas. Thomas described one of the possible areas as “software architecture” - this might be identical with the BTK.
While talking about the bicycle toolkit a small discussion came up. Jim noted that he’d like a “sane way to talk about architecture” which caused multiple ideas and opinions to be stated.
The basic desire is to have an architectural process/expression that provides enlightenment about design decisions.
The points stated included:
- some architectures are too big to express in a conversation or keep in your head, so an oral tradition breaks down
- people seem to understand an architecture better when it is written in a domain they understand
- having experience with a piece of software makes it easier to understand existing designs in comparison to just reading about it
- the documentation may be useful to reason about and review things like data structures used, problems like index accumulation, and unnecessary indirection
- patterns may include parts of the solution, but specifically the community around patterns seems to be focused on the wrong issues (jargon, blowing smoke)
- recording decisions and being able to relate and search problems and solutions maybe be part of the puzzle
Those issues are currently ongoing. We don’t have to discuss them. We just need to follow up on them eventually.
- 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?)
- Repository policy
- Test runners / nightly builds
- Supporting Python 2.7
- Needs help from the buildbots
- Compiler licenses (Tres, postponed until after 2010-06-14)
- Build bot organization
- Bug day organization
- Consolidate “floating” documentation into Sphinx/docs.zope.org
- Write blueprint for the consolidation effort (Theuni) see https://blueprints.edge.launchpad.net/zopetoolkit-project/+spec/consolidate-documentation
- 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)
- Unified index?
- 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.