Sorry about the cross-post, this _is_ just a reply.

 > 
 > Jason Thorpe writes:
 > > ...are you using NetBSD-current?
 > > ... -current can ...  
 > > NetBSD-current also has a properly-implemented ...
 > 
 > I'm still using 1.2 because 1.2.1 hasn't been released yet.
 > And now it seems as if there are already features beyond that
 > mythical 1.2.1 that would be very helpful in running a stable 
 > production system.  But we can't track the nightly changes in 
 > -current because we're using NetBSD in just such as system.  
 > Laine Stump and Jon Ribbens and others have expressed this 
 > concern over just the past few days, and I've resorted to
 > snagging individual kernel sources from the -current tree to
 > fix particular problems.  I don't know what will happen to
 > those fixes if I ever install 1.2.1 (if it's ever released).
 >
 > [ more release and stability comments ]


I think that various release engineers here and there have developed a
attack on this general problem. Possibly, it would help NetBSD.
The theory goes like this...

In general the original problem is that the project is trying to make a
release out of a development code branch. (Or trying to develop on a
release, the point being you need more than one code branch.)

The solution is to anticipate a release and split the code off into the
release branch and the development branch. Bug _fixes_ (at least, those
that don't include major rewrites) go into _both_ branches. You should
actually continue to apply bug fixes even after the release date. (You
can release more often with this scheme, and you can always put an
absolute freeze on the _previous_ release to get a completely static
baseline. The previous release with this system is likely to be a lot
newer than the most recent release is now.)

New development continues in the development branch.

The obvious drawback is that you have to enter and test bug fixes twice,
although cvs may be able to help here. It takes more disk space, etc.

But there are benefits.  [1] you don't have to freeze development prior
to a release. [2] You have a real mechanism for attaining reliability,
rather than just a "pick a decent current and slow down development and
cross your fingers" approach [3] there is less pressure on -current to
be stable [4] there are fewer reasons for people to run -current [5]
its less of a big deal to do a release [6] you _can_ put new features
into the release if they are judged to be "safe" [7] you get a really
nice, static, "previous" release [8] In general, you are in control,
you can just dial in the amount of stability and reliability (vs.
change) you want in a release, and you can bash on as you like in
development.

------------------------------
Ross Harvey		Avalon Computer Systems, Inc.
ross@teraflop.com	Santa Barbara