[Checkins] SVN: zopetoolkit/doc/source/zope-dev/zope-dev-20100525.rst Summary from yesterday.

[Christian Theune]

Log message for revision 112721:
  Summary from yesterday.
  

Changed:
  U   zopetoolkit/doc/source/zope-dev/zope-dev-20100525.rst

-=-
Modified: zopetoolkit/doc/source/zope-dev/zope-dev-20100525.rst
===================================================================
--- zopetoolkit/doc/source/zope-dev/zope-dev-20100525.rst	2010-05-26 06:24:40 UTC (rev 112720)
+++ zopetoolkit/doc/source/zope-dev/zope-dev-20100525.rst	2010-05-26 06:51:36 UTC (rev 112721)
@@ -38,6 +38,18 @@
 - Bug tracking
     - Monitoring tracker status (Charlie Clark, ctheune)
 
+- Documentation
+    - Consolidate "floating" documentation into Sphinx/docs.zope.org
+
+- 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?
+
+- Metrics for bug days
+    - Find a way to demonstrate what/how much work happened on a bug day.
+
 - Meta
     - Review meeting itself, maybe add extra 15 minutes for "meta" once a
       month or every two months? (postponed until 2010-06-01)
@@ -67,4 +79,78 @@
 Summary
 =======
 
-Will be written after the meeting.
+The IRC log is available here:
+http://zope3.pov.lt/irclogs-zope/%23zope.2010-05-25.log.html#t2010-05-25T18:00:25
+
+Windows builds
+--------------
+
+Adam didn't manage to look into the AMIs due to illness. He did draft an
+initial proposal that he started discussed with Christian Theune to get
+funding for a hosted windows build machine from the foundation.
+
+However, Amazon might not be the right choice due to the high cost associated
+with 64-bit machines.  Rackspace's Windows VMs seem to be a viable alternative
+and will be investigated by Adam. Adam and Christian will write a proposal to
+present at the next board meeting on 2010-06-02 that:
+
+- includes a trial period (
+  funding for 1-2 months to set everything up
+  and make sure it does what we need)
+- subsequent cost after the trial period
+- ensures control over the machine is available to the foundation but can be
+  handed over to individual community members easily
+
+An open question is whether 64-bit Windows installations allow installing the
+build chains for 32-bit and 64-bit in parallel. (Adam to ask Sidnei for input)
+
+KGS 3.4.1 release
+-----------------
+
+The KGS release is going to have a release candidate as soon as Adam gets to
+it. He noted that actual .tar and .exe releases will be made on request (the
+option will be stated in the release notes).
+
+In an earlier meeting Adam wanted to write documentation about the release
+process but pointed out that there's already sufficient documentation in
+zope.release that helped him make the releases. Additional baijum and srichter
+pointed out resources
+(http://wiki.zope.org/zope3/DeveloperInfo#release-management and
+http://wiki.zope.org/zope3/MakingARelease) that are related to this.
+
+Tres noted that we might put a new item on our list: generally consolidating
+the documentation floating around into the Sphinx documentation we have on
+docs.zope.org.
+
+Bugday review
+-------------
+
+Individual reports:
+
+- Adam investigated Azure for building packages instead of using Amazon but
+  that turned out to be a dead end. Azure is more like GAE than rented virtual
+  machines.
+
+- Christian Theune worked on emptying out the Zope 3 bugtracker and fixed some
+  bugs along the way. There's 25 bugs left in the tracker now.
+
+- Jens Vagelpohl worked on Zope 2 bugs and hit a dozen.
+
+- Tres landed a patch from bzr and made releases of packages in the aftermath.
+
+- Baijum wrote a few test cases for zope.mkzeoinstance.
+
+Christian Theune noted that we should ponder how to establish a rule for
+releasing packages after bugs were fixed without making individual releases
+for every change. Having releases shortly after a bug day (like Tres did)
+seems reasonable.
+
+We also would like to have some metrics that show what happened on a bug day.
+Various options were raised: 
+
+- note bugs that have been worked on in the wiki
+- tag bugs with a unique tag
+- use a query in LP for "everything that changed on day X"
+
+The next bug day will be agreed upon with an open doodle to the Zope
+developers list, Christian will invite for the week that includes 2010-06-15.