Date: Tue, 12 Dec 1995 17:20:42 +0300 (????) From: Dmitry Khrustalev <dima@bog.msu.su> 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? Message-ID: <Pine.SOL.3.91.951212171552.15095B-100000@sunny.bog.msu.su> In-Reply-To: <17174.818735027@time.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SOL.3.91.951212171552.15095B-100000>