From owner-freebsd-stable Tue Dec 19 00:10:44 1995 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA29778 for stable-outgoing; Tue, 19 Dec 1995 00:10:44 -0800 (PST) Received: from mail.barrnet.net (mail.barrnet.net [131.119.246.7]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id AAA29773 for ; Tue, 19 Dec 1995 00:10:42 -0800 (PST) Received: from sunny.bog.msu.su (sunny.bog.msu.su [158.250.20.1]) by mail.barrnet.net (8.7.1/MAIL-RELAY-LEN) with SMTP id GAA02915 for ; Tue, 12 Dec 1995 06:36:48 -0800 (PST) Received: (from dima@localhost) by sunny.bog.msu.su (8.6.12/8.6.12) id RAA15120; Tue, 12 Dec 1995 17:20:43 +0300 Date: Tue, 12 Dec 1995 17:20:42 +0300 (????) From: Dmitry Khrustalev To: "Jordan K. Hubbard" cc: Nate Williams , stable@freebsd.org Subject: Re: Bringing stuff into 2.1? In-Reply-To: <17174.818735027@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-stable@freebsd.org Precedence: bulk On Mon, 11 Dec 1995, Jordan K. Hubbard wrote: > > 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) Jordan, while IPX represents new functionality, it is independent from the rest of the kernel and is optional. It's like a driver for new device. Why not bring it into -stable ? -Dima > 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 >