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

[Jim Fulton]

Tres Seaver wrote:
> Chris Withers wrote:
> 
>> Tres Seaver wrote:
>>
>>> Chris,
>>>
>>> I would call the 2.6 branch "closed except for serious security 
>>> bugs"; please don't check in new features or minor bugfixes there.
>>
>>
>>
>> How come? and was this announced anywhere?
> 
> 
> See the last topic in:
> 
>   http://dev.zope.org/CVS/ZopeDevelopmentProcess

Hm. This document is (understandably), a bit too ZC-centric.
I think we (as in the Zope Community "we") need to fix this.


>> I don't see what harm applying minor bugfixes to any release branch 
>> could do...
> 
> 
>   - It is a well-established principle of software engineering that the
>     most likely source of new bugs in mature code is fixes for old ones.
> 
>   - People who are still running 2.6 in production are demonstrably
>     risk-averse (and often for good reason).  Adding non-critical fixes
>     to the "mature" branch increases the amount of risk involved in
>     upgrading production sites, which they typically won't do except to
>     close major security vulnerabilities.
> 
>   - If something comes up which forces us to make a 2.6.5 release,
>     keeping the diff from 2.6.4 as small as possible is a real goal
>     for the release manager, who must communicate with the risk-averse
>     sysadmins.
> 
>   - As a parallel, think about the kinds of changes you want to see
>     *today* to the 2.2 Linux kernel:  if you are still running sites on
>     2.2, you definitely don't want *any* non-essential fixes being
>     backported there.

These are good points os rational that should go into an updated process doc.

Clearly, new features shouldn't go into a bug-fix or maintenance branch.

Then the question is: what's a minor bug fix?  I don't know who decides that.

I think we (community) need to think about a better release-management process
that allows the community to make progress without being subject to Zope Corp
resource availability.

There are two issues:

- Volunteers

- Process

Maybe we can spend some effort trying to improve the process.

Perhaps we can discuss some ideas.

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.

It would be great if someone would volunteer to update the process doc.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org