From owner-freebsd-stable Mon Dec 11 18:25:13 1995 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA28412 for stable-outgoing; Mon, 11 Dec 1995 18:25:13 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id SAA28406 for ; Mon, 11 Dec 1995 18:25:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id SAA17177; Mon, 11 Dec 1995 18:23:47 -0800 To: Nate Williams cc: stable@FreeBSD.org Subject: Re: Bringing stuff into 2.1? In-reply-to: Your message of "Mon, 11 Dec 1995 16:09:30 MST." <199512112309.QAA07505@rocky.sri.MT.net> Date: Mon, 11 Dec 1995 18:23:47 -0800 Message-ID: <17174.818735027@time.cdrom.com> From: "Jordan K. Hubbard" 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! > For example, the sliplogin/slattach changes could go in (they've been > running here for months now), but I'm not sure if we want them to go in. I'd say that this qualifies since the 2.1 slattach was already substantially merged from 2.2 before we shipped (you'll recall my railing against our broken slattach). If the evolutionary process has continued in 2.2, and it doesn't jeopardize functionality, cool. > I'd also like to see the PPP stuff move in, and even the ibcs2 kernel > stuff, but I'm not heading in that direction until we have an idea what > the policy is going to be. The iBCS2 stuff is a little iffy, but I'd argue that #2 could be ammended slightly for anything not on the critical path. ibcs2 stuff doesn't fall into that category, and if the changes result in better ability to run MORE binaries, I don't see why it shouldn't be brought across (given provision 4). 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. :-) Jordan