[Zope-dev] Better release management (was Re: Zope 2.6 branch "closed for bugfixes"?)

[Chris McDonough]

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