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:
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@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org