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.

Attachment: smime.p7s
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 )

Reply via email to