Re: [HACKERS] A small problem with the new inet and cidr types

The Hermit Hacker <scrappy@hub.org> writes:

>     and I think incorporating it at this late a date in the release
> cycle would also be a mistake.

While we're talking of release cycles, I'd like to take the liberty to
post something that I've been keeping around for a while, which was
written by Dave Burgess (of *BSD FAQ fame) some time back.  He was
posting to a NetBSD mailing list, so there is wording in here that's
specific to that environment, but there is much good, general truth
here.  With respect to the CIDR case, note especially his "get it
right or get it out" rule.  Translated to PostgreSQL 6.4 terms, we
get: "Whoah!  This wasn't what we wanted!  Decide quick: do we ship
what we have, or do we ditch it and do it right for 6.5?".  We chose
to do neither, and there's a lesson to be learned from this.

Let me also take this opportunity to submit a plug for "The Mythical
Man-Month" by Frederick P. Brooks.  Anyone involved in software
development who hasn't yet read it, should.  Get the 1995 special
edition, expanded and edited from the original.

Anyway, here's Dave's writing on release engineering:

| 1.  When the interface to a system changes radically, the major number
| should be bumped.  The minor number should be reset to 0.
| 
| 2.  When more than 50% of the code in a system has been changed, the
| major number should be bumped EXCEPT if the minor number is 0.  This
| takes into account the case where a recent interface change drives a
| large code churn.
| 
| 3.  There should be a target list of changes for each release.  When
| those changes are accomplished, the minor number should be bumped unless
| the minor number was reset to 0 by 1 or 2 (above).  The target list
| should also have a target date (six months is a good consensus
| timeframe, from what I've heard). 
| 
| NOTE:  If the list only has one item on it, but a bunch of other
| projects have been started, then when that single item is ready to roll,
| everyone has to be ready to either get it right or get it out.
| 
| 4.  Once the target list is complete, all changes in progress are
| brought to closure and the system is Alpha released.  The Alpha baseline
| is established.  This means either backing out the work in progress or
| bringing the work to a state where it is working or will not impact
| performance.
| 
| 5.  The bugs from the Alpha test cycle are documented and analyzed.  If
| there are no Class A or Class B problems (A being "causes damage to
| equipment or files" and B being "causes reproducable system halts and
| panics") the code should be promoted to Beta.  If there are, these
| problems are addressed.  The Alpha is then re-released.  All SPR driven 
| changes are made to the Alpha Baseline code and the -current code.
| 
| 6.  Once the Beta has been released, a firm release date is established.
| For most of the Govt project I've worked on, that is 28 days out.  If no
| new Class A or Class B SPRs are received, the code is released on the
| release date.  If there are Class A or Class B SPRs, the changes are
| made.  The release date does not slip.  For us, a 14 day lead should be
| plenty.
| 
| 7.  If the release date cannot be met, a new Beta is released and a new
| release date is established.
| 
| The advantage of this is that there are a few driving upgrades that
| force new releases.  As an example, we could have established a short
| list of "2.0 candidate targets."  which could have included "bounce
| buffer support" and "working 100MB/s drivers for all existing network
| cards."
| 
| The logistics for this are daunting, but are workable.  We are already
| working using good CM practices, our testing is good, and the source
| code baseline could literally happen almost anytime.
| 
| The trick, then, is to find someone willing to do the Release
| Engineering.  It's a shame we don't know anyone with years of experience
| doing this....
| 
| Now for the schedule in real terms:
| 
| Day 0 - The list of existing "work in progress" and "need to fix"
| problems is culled for the next release.
| 
| Day 20 - The list is agreed upon; if anyone disagrees with the
| feasability of an item for the releas in 5 months, it is defered.
| 
| 100 days pass for people to work on their projects.  This should be
| enough to at least get to the point that you know whether you will make
| the deadline.
| 
| Day 120 - The release candidate is checked for completion of the list.
| The list is reviewed for possible deletions.  Work continues.
| 
| Day 150 - The release candidate is checked.  This is the "drop dead" for
| the projects in work.  Everything that is working stays, everything else
| is either removed or neutered.  This is the Alpha release.  At this
| point, the -current tree is baselined, as is.  Work on -current
| continues while the Alpha and Beta trees are used strictly for Problem
| reports.  Yes, this involves making the changes twice; once in the Alpha
| tree and once in -current.
| 
| Day 165 - The Beta is released.  Changes to the Alpha source tree are
| included and the Beta tree is baselined.
| 
| Day 180 - The release is cut and the next version list is started,  Day
| 0 is today for release +.1.

-tih
-- 
Popularity is the hallmark of mediocrity.  --Niles Crane, "Frasier"