I'm in a replying mood, so...

Bob Sutterfield wrote:

>> Jason Thorpe writes:
>> ...are you using NetBSD-current?
>> ... -current can ...  
>> NetBSD-current also has a properly-implemented ...

These are the types of responses I expect from Jason, either on
a netbsd-help, or netbsd-users question, because he can't help until
he knows what you are using. If you don't want to run any version
of -current, then perhaps that would be an appropriate part of the
question: "On NetBSD 1.2 is there a way to..."

>I'm still using 1.2 because 1.2.1 hasn't been released yet.

I thought it had been out for quite some time now, the 
/pub/NetBSD/NetBSD-1.2.1 directories are dated mid to late
March.

>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. 

I'm not sure which features you are referring to. See above note
wrt 'mythical'. 

> But we can't track the nightly changes in 
>-current because we're using NetBSD in just such as system.  

There are many options in how you 'track' -current. It is of 
course an option to use sup daily, and have up to the minute
souces, but all the documentation says that -current is not
for production systems, "we don't even guarantee it will
compile on any given day". Another option is to grab -current and
run it on a non-production machine - Watch the mailing lists, if
there are problems with the code, you'll either see it on your
test machine, or you'll see postings about what other people
are seeing. personal-opinion: If you don't see any major problems
popping up after a couple of weeks, you can try running your
production software on it, but of course be ready to go back if
you have to.

>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).

They would be overwritten if the patches are off of the 
-current development branch.
BTW, the ongoing (if ever released) type comments don't help
anything, they tend to just aggrivate tempers, and don't
actually accelerate a release.

>I understand this is the nature of a Net project, that its 
>releases are never as neat and tidy as a commercial product.

I don't follow this one, again, personally, NetBSD releases
are more stable than most commercial products I buy. I find
the core team unwilling to settle for anything less than the
most neat and tidy releases possible, even enduring the
net-pressure and holding releases back at times.

> [...]
>But it's faint 
>comfort to hear that the only way to get the fixes is to 
>run an ephemeral -current!  I'm a true believer in this OS 
>and in the benefits of free software, but I also have to 
>answer my bosses' questions about system reliability.  It's
>getting harder and harder to resist buying an OS.

I'm not sure what you mean by 'ephemeral -current' (?)
Obviously satisfying your boss is important, but hopefully
your boss hired you because you know what you are doing, and
lets you do your job. If you can't resist buying an OS, then
go ahead, but remember that you likely won't have access to
any interim development like -current. You won't be able to
ask questions to the people who actually do the development.
You probably won't get source code. You won't be able to
submit patches, won't have much input into future development
get to pay up front, and for updates, and have support
only 9-5 M-F.

I'm sure many people could offer you source sets with the
features you want from a stable period in -current, 
there are people who keep snapshots from many of the
platforms in binary form too.

>--
>Bob Sutterfield                         +1 909 794 1151
>Mission Aviation Fellowship / MAFlink Technical Manager
>mailto:Bob@XC.Org                 http://www.XC.Org/bob
>             Pray Globally - Serve Locally

Ross Harvey wrote:
> 
> 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 NetBSD group does this around release time. But resources aren't
plentiful enough to do this all the time (I think), and volunteers
like to work on the fun stuff, which is generally the new things.

> [...] 
> 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.

You've very accurately described how things are done now.

> 
> 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.

It would be worthwhile to review some of the mailing-list archives
from around release time and you will see that this is exactly how
things work.

A main point is that the NetBSD team isn't overly concerned to appealing
to end users like say Linux does. New releases have feature sets
determined 
that the team would like to accomplish, and they work towards it, 
I applaud them for not bowing to pressure to release early, or change
the effective methods they follow now. I'd like to see a semi-official
snapshot set produced more regularly, but I respect what the core 
has developed, both code and procedures.

						David Maxwell

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