Hi,
here's yesterday's minutes. I've been a bit less adventurous than last
week and we're back on a text format. Unfortunately without tool support
again, for now. :/
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-04-20 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-April/040226.html
The IRC logs are located here:
http://zope3.pov.lt/irclogs-zope/%23zope.2010-04-20.log.html#t2010-04-20T18:02:52
Version/release issues with ZTK packages
Adam Groszer reported that in his work for the Zope 3.4.1 KGS he stumbled over
problems with releases that improperly mixed features and bugfixes in major an
minor releases.
Tres and Adam suggested to remedie situations like this (where a minor release
introduced features that break stuff) by making two new releases: a subsequent
minor release that removes the features again and a subsequent major release
to properly introduce the feature changes.
Christophe Combelles specifically reported zope.app.securitypolicy as an
example breaking z3c.formdemo. It seems like Martijn Faassen made that release
so we need to check back on his oppinion.
Tres noted that for packages that are developed with a specific version set in
mind their buildout should point to that index. This will ensure successful
builds and document the context they have been developed in.
Christophe Combelles noted that we might want a tool to support developers
verifying whether a release would be suitable for major or minor version.
agroszer will report other packages he found having those kinds of issues to
the Zope 3 bug tracker.
The general approach of re-releasing packages when features have crept in
should be documented in the developer documentation (Christian Theune).
LP bug management / Triage of old Zope 3 bugs
=
Tres' and Christian spend some time cleaning up the Launchpad situation.
Details are to be found in Tres' blog post:
http://palladion.com/home/tseaver/obzervationz/2010/ztk_launchpad_gardening
It wasn't clear what should happen about bug tracking for code that lives in
zope.app.* packages as those aren't part of the ZTK itself anymore.
We discussed having a separate Launchpad project group 'zopeapp' for them and
create individual projects there.
Christian Theune suggested to ponder merging the zope.app.* packages into a
single distribution and thus having a single zopeapp project. As one goal is
to slowly shrink the size and number of zope.app.* packages in use this could
reduce the amount of overhead involved to manage the packages. The decision on
this was deferred to the ZTK engineering group.
[Note: we still need to do something about bug tracking *now*. Proposal for
next time: go with a single zopeapp project with a single bug tracker for
now.]
[We didn't touch the issue of triaging bugs from the Zope 3 tracker to the
individual packages' ones. It would be cool, though, if people had time before
the bug
day to actually move more of them over to the individual projects]
Upcoming bugday
===
As a gentle reminder: there's a bug day coming up on Saturday 2010-04-24 and
anyone who wants to help getting bugs triaged or fixed and who wants to
contribute or help out otherwise is very welcome.
Tres' will provide some documentation to help non-comitter volunteers
interface with our development process which can later be incorporated into
docs.zope.org.
___
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 )
