Hi, sorry for the delay sending the protocol, this week was rather busy, so I lagged catching up. Here it is, anyway.
When meeting next Tuesday, I propose to spend 15 more minutes than the other days, for a general review of the weekly meetings and how to conclude the experiment. I suggest you get a bottle of wine or beer before that and ponder about some feedback and possible improvements or suggestions about the experiment. Cheers, Christian -- Christian Theune · c...@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development
============================= Weekly Zope developer meeting ============================= This is the summary of the weekly Zope developer meeting which happened on Tuesday, 2010-03-23 on #z...@irc.freenode.org from 3pm to 3:30pm (UTC). The agenda for this meeting is available in the mailing list archives: https://mail.zope.org/pipermail/zope-dev/2010-March/039839.html The IRC logs are located here: http://zope3.pov.lt/irclogs-zope ZTK release management ====================== We did not receive nominations nor did any volunteers step up. We re-visited the idea of a single release manager versus a small working group as the main goal of the release manager would have been to foster communication with the various consumers of the ZTK to get to a common definition. Tres suggested to establish a working group with representatives from a set of consumers (initial suggestion was Zope 2, Grok, Bluebream). (We haven't figured responsibility for approaching them -- I'll do that in the next days.) This setup would resemble what the steering group was intended for but has a more specific task (drive the definition of the ZTK and towards the 1.0 release). Bug tracking ============ The individual packages that resemble the ZTk aren't managed properly with respect to bug tracking (that includes triaging bugs and fixing them). The main issue is that there's no defined point where bugs for those packages should be reported and managed. Historically there is the Zope 3 bugtracker on Launchpad (LP) and a set of related projects that were established (by me) during last EuroPython to go towards a more fine-grained approach of tracking bugs to allow using LP's release management/version tools. In the long run, we probably want the bugs to be tracked with individual projects and a corresponding project group, however, this currently causes more confusion than it helps, especially as we have old bugs in the Zope 3 tracker. I volunteer to approach the LP people at EuroPython to figure out how to do this reasonably. (Managing many projects is cumbersome as we need to ensure the list of packages in the LP project group to stays in sync with the ZTK list, give out access, ...). In the short term we will create a ZTK project, dissolve the individual package projects and perform triaging of Zope 3 bugs into the ZTK project, then closing the Zope 3 project.
Description: S/MIME Cryptographic Signature
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )