On Wed, 2004-04-21 at 14:57, Jim Fulton wrote: > Here's one: For each release (e.g. 2.8, 2.9) identify a small > team of release managers. This team would be responsible for > planning and executing the release, including bug-fix releases > for that base release. That team could establish the policy for > changes to that release, possibly including vetting fixes.
Maybe it would be better to start with absolving ZC of the responsibility of creating maintenance releases, with the goal in mind for feature releases to be managed more by the community at some point. In the interim, ZC would still be responsible for setting the timeline and feature set goal for major releases at least for 2.8 and 2.9. I suggest this because ZC has already set the goals for 2.8 and 2.9 and they seem pretty much non-negotiable if we want a Zope 3 transition plan. I suspect ZC will want to maintain control over the featureset and timeline during this (critical) period. Asking for help without providing any direct control or input into the featureset and timeline to the helpers might not work very well: not everyone in the Zope community is as concentrated on the Zope 2 -> Zope 3 transition plan as is ZC. I might be wrong about this, I'd be interested to hear any opinions to the contrary. This also mirrors the current Python process where the timeline for maint releases is largely controlled by someone outside the core feature development team (poor Anthony) but the timeline/featureset for feature releases is largely still controlled by the core development team. - C _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )