Subject: Re: detecting -current versions
To: Brian R. Gaeke <brg@dgate.org>
From: David Maxwell <david@spinne.web.net>
List: current-users
Date: 09/03/1995 19:45:16
Brian said the following: 
> And then spake Andrew Gillham as follows:
> > > But would this not violate core's policy of not giving out old sources
> > > to 'just anyone(TM)'? [...]
> > [...] There is no need to get old sources from core if you base it on
> > -current as of right now.  [...]
> 
> True. 
> 
> > > virtually, (retch, retch -- better name for this. "Interim"?)
> > Well NetBSD 1.0i1 or NetBSD 1.0I1 could be confusing.  How about
> > using "pre-release" with 'NetBSD 1.0p1' or something?
> > (I know, could be considered 'patch-level 1' I suppose)
> 
> Sounds ok. The name is not the most important thing... :)

The name is rather important. For one particular reason. Interim, or 
Pre-release sounds like an 'official' release of sorts. To me anyway,
virtual doesn't have the same connotation. I'm not fussy about the word 
either, suggestions welcome, but virtual in this case implies to me that
I'm getting something kind of like a release but which isn't really a
_RELEASE_ (from core). I think that whatever the terminology becomes it
should reflect this.

> > PS.  I would think that anything done would need to be blessed by core.

That depends. If someone wanted, I'm sure they could set up a server and
start serving virtual releases whether core approved or not. What _I'd_
much rather see though is a well designed mechanism that could be integrated
into the way things work now, so that it would support development, and
the core team, and NetBSD as a whole. If we could do this in such a way that
the core team gets benefits from it, and cuts their workload some, and it
is clearly distinct from full NetBSD releases, I don't know what core's
objections would be. (But that's what Email is for ;-)

I think this might get long winded, but here are some benefits I see.

1. Having a structure for V-rels (I'll use that term for now) means people
could be more self-supporting. With a well designed web page, people could
look up known problems based on their current V-rel. This could even tie in
to PR's, which could be fixed as of a certain V-rel.

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.

3. This would assist in tracking progress towards the goals set for the
core team's next Full Release.

4. Patches could be built for upgrading between V-rels without getting the
full tree from scratch, which saves time and bandwidth.

5. More people might run NetBSD with access to a more structured environment.

> I would think so, too. Who would be the one(s) to make such releases?
> (I would doubt that core itself would want to.)

My idea would not involve any ongoing work on the part of core. There might
be some one-time work on gnats, sup, or the home pages, but we should be
able to come up with drop-in stuff for and changes.

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.

							David Maxwell
							david@web.net