Zope 2.6 branch "closed for bugfixes"?
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? I don't see what harm applying minor bugfixes to any release branch could do... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
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
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. Tres. -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com
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
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
participants (4)
-
Chris McDonough -
Chris Withers -
Jim Fulton -
Tres Seaver