[Checkins] SVN: zopetoolkit/doc/source/zope-dev/zope-dev-20100713.rst Summary for this week

[Christian Theune]

Log message for revision 114794:
  Summary for this week
  

Changed:
  A   zopetoolkit/doc/source/zope-dev/zope-dev-20100713.rst

-=-
Copied: zopetoolkit/doc/source/zope-dev/zope-dev-20100713.rst (from rev 114239, zopetoolkit/doc/source/zope-dev/zope-dev-20100706.rst)
===================================================================
--- zopetoolkit/doc/source/zope-dev/zope-dev-20100713.rst	                        (rev 0)
+++ zopetoolkit/doc/source/zope-dev/zope-dev-20100713.rst	2010-07-16 06:21:46 UTC (rev 114794)
@@ -0,0 +1,127 @@
+==========
+2010-07-13
+==========
+
+This is the agenda and summary for the weekly Zope developer meeting of
+Tuesday, 2010-07-13 on #zope at 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-13.log.html#t2010-07-13T17:57:24
+
+Attendees
+---------
+
+Christian Theune, Charlie Clark, Tres Seaver, Fred Drake, Hanno Schlichting
+
+Abandoned projects
+------------------
+
+Tres reported that there are a bunch of projects in SVN that nobody seems to
+care about (at least enough to update copyright heads, conform to policy,
+...). In the long run those may need to be moved away from the main tree or
+repository to signal that they're not actively maintained.
+
+We'd like to take action to figure out which of those projects really aren't
+maintained anymore.
+
+A first step for this would be to make it more visible who the developers are
+that (used to) maintain the code. The idea came up to enhance the repository
+policy report with the information of "when was the last commit", "who were
+the frequent committers for this branch". This would allow developers to
+quickly scan the list of projects for their name and thus check faster whether
+any of the projects they are interested in needs attention.
+
+Charlie Clark volunteered to make the necessary changes to the repository
+policy checking code as soon as he has time in the next week(s).
+
+ZTK vs Python 2.7
+-----------------
+
+The mailing list thread about ZTK/Python 2.7 was picked up. Tres expressed interest in supporting Python 2.7 ASAP.
+
+For ZTK 1.0 there are multiple reasons not to support Python 2.7:
+
+* ZTK 1.0 still needs to support Python 2.4 and supporting many Python
+  versions in parallel (2.4-2.7) is maybe not a good idea
+* ZODB 3.9 isn't compatible and upgrading to 3.10 won't happen before ZTK 1.1
+
+ZTK 1.1 then could drop support for Python 2.4 and upgrade packages to get
+them in a version that supports Python 2.7.
+
+Windows help needed
+-------------------
+
+Tres noted that we're notoriously short on Windows developers that help fixing
+bug. If you're a Windows developer then we would appreciate if you could help
+fixing bugs quickly that appear on Windows as none of the core developers run
+Windows as their primary working environment.
+
+
+Agenda
+======
+
+- Abandoned projects (Tres)
+
+Ongoing issues
+--------------
+
+Those issues are currently ongoing. We don't have to discuss them. We just
+need to follow up on them eventually.
+
+- 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?)
+
+- 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.