>> support point simply because they're likely the only ones who know for sure
>> what went into each snapshot.  Any portmaster without the resources of a
>  Not if a source snapshot goes along with each binary snapshot.

If the question "what bugs are present in this" could be answered quickly and
easily by reading the code, software maintenance wouldn't be the nightmare
that it is.  (And I might be able to discover if this "free time" thing really
is all it's cracked up to be.  ;-)

>> this means that someone intending to put out a multi-architecture CD has to
>> have a separate source tree for each architecture -- this is not the way to
>> encourage companies to package NetBSD on CD.
>  A disadvantage, to be sure--but then, I've never really understood the
>intense need that a lot of people seem to have for having their OS's
>distributed on CD.

Leave college (assuming, unwarrantedly, that that's the reason you have a .edu
address).  Get a modem connection, especially in a rural area with poor phone
lines.  You'll gain a new appreciation for CDs.

Or:  lose a disk.  Now, do you want to (a) spend all day babysitting a download
and unpacking gzip'ped tar files and recompiling, or (b) pop in a CD, run a
command, and be done with it?  Now, method (a) is great if you're trying to
avoid studying, perhaps, but few people have the bandwidth into their homes
to make (a) more rewarding for those with limited hobby time.

	I would also point out to the general audience that the commonly-seen
	sentiment "I've never really understood the intense need that a lot
	of people seem to have for <anything differing even slightly from
	my preferences>" is a significant part of why Linux and FreeBSD have
	more users (even if not the greatest part):  they *cater* to people
	who want to use their systems a bit more, and by golly, people *use*
	their systems more.  (Of course, the core group has turned down a
	number of suggestions that would have made NetBSD even more mass-user
	hostile from some of the "I've never really understood..." crowd.)

> It's seems so...static--guaranteed to be obsolete by
> the time it's available--kind of like releases, actually, but with the
> additional delay time incurred by burning and shipping CD's.

Two whole weeks?  The horror!  Any portmaster who is willing to go through
the snapshot process more frequently than that is badly in need of both
(1) a life, and (2) lessons in quality release engineering (hey, if you
aren't going to TEST IT, work for Microsoft).

(Actually, the company I work for got 1 week turnaround on CD orders for our
first CD, for a 2000 CD run (I think it was).  Stuffing boxes took another
week, but that's less of an issue for most shovelware CD houses.  By far,
the longest part of preparing the first release (counting from the final
freeze date) was running the regression tests, verifying that the "must work"
tests worked, analyzing the problems in the "we'd LIKE them to work" tests
and deciding whether or not it was good enough to inflict on, er, ship to
users.)

It's a simple, observational fact that there are a lot of people who vastly
prefer canned CDs for their operating systems.  Arguing that it shouldn't be
so is like arguing that the sun should rise in the West and set in the East.
Torpedoing a proposed release strategy because people should not prefer CDs
makes precisely as much sense as torpedoing it because the sun rises in the
wrong place.