From owner-freebsd-current  Sun Dec  8 17:10:30 1996
Return-Path: <owner-current>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id RAA05302
          for current-outgoing; Sun, 8 Dec 1996 17:10:30 -0800 (PST)
Received: from broon.off.connect.com.au (broon.off.connect.com.au [203.63.69.1])
          by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id RAA05296
          for <freebsd-current@freebsd.org>; Sun, 8 Dec 1996 17:10:26 -0800 (PST)
Received: from connect.com.au (ggm@localhost) by broon.off.connect.com.au with ESMTP id LAA15136
  (8.7.6h/IDA-1.6); Mon, 9 Dec 1996 11:09:03 +1000 (EST)
X-Authentication-Warning: broon.off.connect.com.au: ggm owned process doing -bs
To: Chuck Robey <chuckr@glue.umd.edu>
cc: freebsd-current@freebsd.org
Subject: Re: siguing into current from a random version 
In-reply-to: Your message of "Sun, 08 Dec 1996 20:03:12 EST."
             <Pine.OSF.3.95.961208195851.10130A-100000@downlink.eng.umd.edu> 
Date: Mon, 09 Dec 1996 11:09:03 +1000
Message-ID: <15134.850093743@connect.com.au>
From: George Michaelson <ggm@connect.com.au>
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk


Snaps are good but the timelag between snaps and interesting state in current
is bad. If you're saying that for any given SUP state you can go from the
last snap to current without tripping over any non-reversable states, well
and good.  I don't think you're saying that :-)

I suppose an assumption many neophytes like myself make is that CVS commits
happen to complete sets of *tested* changes and not work in progress, so that
the worst-case state is the testing (by author/cvs-changer) didn't cover for
ones own particular setup and circumstances. 

Looks like you're saying its more fluid, and simply doing a make world on
the result of a sup on current is caveat emptor.

I can handle that, if there is some indication in the logs/readmes/mail to
say when its known current is unrunnable.

Thats kinda what the NetBSD doc/CHANGES is all about: things in there reflect
coarser grain documentation than individual CVS commits. By the time its
logged there, its probably 1/2 way stable.

It looks to me like the best bet for a time to re-sync is the xmas holidays
since the frequency of changes to CVS will be lower... 

-George