Not long ago, Andrew Gillham said: 
> Quoting David Maxwell:
> > is clearly distinct from full NetBSD releases, I don't know what core's
> 
> Hmm, I personally don't like the "clearly distinct" part.  Sounds too
> much like a splinter.  I prefer having core providing snapshots, or
> core approving who is providing the snapshots.  Not that they have to,
> but we don't want the distributor of the weekend reputation like Linux
> has.  i.e. Netbsd 1.0, Fred's NetBSD 1.0, Killer NetBSD 1.0, Slackoff
> NetBSD 1.0, etc.. all being _different_.

No, I'd definitely like to see a unified numbering scheme, not something like
you mention about Linux.

> > 2. Likewise, people could pick the right V-rel to get the new features they
> > want in an update, without worrying about individual file versions.
> 
> Well, how would bugfixes .vs. new features work?  I would think a micro
> release would just be a known stable snapshot.  Generating a new micro
> release would make previous ones obsolete.

I would think new features require upgrading to a new micro release.
Patches would just be fixes to bugs (panics, and other crashes) known to have
been present at the time of a certain micro release.

> > 4. Patches could be built for upgrading between V-rels without getting the
> > full tree from scratch, which saves time and bandwidth.
> 
> Upgrade kits are a good idea, but seem more appropriate for _real_
> NetBSD releases.  I guess it would depend on how often you generated a
> micro release.

I think they'd be useful in both situations. A patch kit could often be much
smaller than getting a full release from scratch.
 
> > 5. More people might run NetBSD with access to a more structured environment.
> 
> I don't really think the current release environment is unstructured.
> The problem is just that the releases aren't often enough.  I would be
> happy to see a NetBSD 1.1 now, and a NetBSD 1.2 in about 6 months.  Or
> a NetBSD 1.1.1. I guess.  I'll agree that the -current method is not
> structured from the standpoint of "releases" but it isn't meant to be.
> I think more people would run NetBSD if we had a friendly install
> utility.  (and maybe more packages)

True, my wording was unclear. I feel the current _Release_ scheme is perfect,
and I appreciate the core's scheduling full releases for a time when they
feel the job is done. I have no complaints about the time between 1.0 and 1.1

I would like to see more structure for those people wishing to run -current
though, and I don't want to pile on work for core to set that up, I think we
can organize an effective support network for -current.

> > The way snapshots are made, and who makes them now would not change, we
> > would just add more structure to the way they are made available. I can
> > probably provide a Web site for doing the things mentioned above.
> 
> I'm not sure I understand this part.  I thought you were saying that
> someone "clearly distinct" from NetBSD would be making the
> snapshot/virtual/micro releases?

I'll try to word this carefully. Hopefully, those people doing snapshots now
would be willing to continue, and whatever structure we provided would 
simply ease the identification of such snapshots. I meant clearly distinct
in the way that -current snapshots are clearly distinct from NetBSD releases.
My reference to providing a site could be for allowing ftp of such
micro/virtual/pre/interim releases, as well as a Web page database of the
information about features, bugs, and patches.

							David Maxwell
							david@web.net