Date: Mon, 11 Dec 1995 23:31:52 -0700 From: Nate Williams <nate@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? Message-ID: <199512120631.XAA08347@rocky.sri.MT.net> In-Reply-To: <17174.818735027@time.cdrom.com> References: <199512112309.QAA07505@rocky.sri.MT.net> <17174.818735027@time.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199512120631.XAA08347>