From owner-freebsd-stable  Mon Dec 11 22:29:30 1995
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id WAA10668
          for stable-outgoing; Mon, 11 Dec 1995 22:29:30 -0800 (PST)
Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id WAA10662
          for <stable@FreeBSD.org>; Mon, 11 Dec 1995 22:29:27 -0800 (PST)
Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id XAA08347; Mon, 11 Dec 1995 23:31:52 -0700
Date: Mon, 11 Dec 1995 23:31:52 -0700
From: Nate Williams <nate@rocky.sri.MT.net>
Message-Id: <199512120631.XAA08347@rocky.sri.MT.net>
To: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Cc: Nate Williams <nate@rocky.sri.MT.net>, stable@FreeBSD.org
Subject: Re: Bringing stuff into 2.1? 
In-Reply-To: <17174.818735027@time.cdrom.com>
References: <199512112309.QAA07505@rocky.sri.MT.net>
	<17174.818735027@time.cdrom.com>
Sender: owner-stable@FreeBSD.org
Precedence: bulk

> > Since the next release is going to be 2.1.1, what's the policy for
> > bringing in changes to the 2.1 branch from -current?
> 
> 1. If you're sure of the change.
> 2. It doesn't represent radically new functionality (like devfs or IPX)
> 3. It fixes a bugs or otherwise corrects something that needs correcting
>    (like a missing man page or re-written for clarity doc)
> 4. It's been tested for awhile in -current.
> 
> Go for it!

All right.  What kind of time-frame are we looking at here?  The reason
I'm asking is I want to shake out some of the more 'critical' portions
of the merge (any of the kernel mods I'd like someone else to look over
before they go in) and I don't want to push things to the wire.  Is a
'drop-dead' date of February a workable goal, so it leaves us all of
February for a Real(tm) beta-test cycle?

> My (and I believe everyone's) chief concern is that we not break the
> tree.  That means being _really_ careful the ensure that any changes
> brought across don't have dependencies on other areas of -current
> which may not also make it in.  The last thing we need is to break
> _all_ ibcs2 binaries (or something) because only half of the
> components were brought over. :-)

Right.  I'll make sure (in a test environment even) that it works w/out
any other changes.  But, I wanted to get the go ahead to do it before I
spent the time doing it.


Nate