Tres Seaver wrote:
Chris Withers wrote:

Tres Seaver wrote:


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:

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

  - 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 Fulton           mailto:[EMAIL PROTECTED]       Python Powered!
CTO                  (540) 361-1714  
Zope Corporation

Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists - )

Reply via email to