From owner-freebsd-hackers Sat Mar 9 13:33:25 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA26259 for hackers-outgoing; Sat, 9 Mar 1996 13:33:25 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA26253 for ; Sat, 9 Mar 1996 13:33:20 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id NAA13442 for ; Sat, 9 Mar 1996 13:33:16 -0800 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA21373; Sat, 9 Mar 1996 13:53:57 -0700 From: Terry Lambert Message-Id: <199603092053.NAA21373@phaeton.artisoft.com> Subject: Re: When is 2.2 Estimated to be released? To: peter@jhome.DIALix.COM (Peter Wemm) Date: Sat, 9 Mar 1996 13:53:57 -0700 (MST) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Peter Wemm" at Mar 9, 96 07:32:17 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: owner-hackers@FreeBSD.ORG Precedence: bulk > >I'd like to see the code differential from 2.1.0 to 2.1.5 be the same > >as the code differential between 2.0.5 and 2.1.0. > > Dont forget, doing a side release branch is a trememdous amount of work, > as I'm sure David G. will testify to. All effort spent on the side-branch > is directly taken away from major features in -current. I'm actually agruing *against* side releases when a date comes up with planned features not present. I think the "let's do a side release instead" response is unwarranted. > The improvements noted are only a small fraction of what's been going on. > There are a lot of general cleanups and improvements in -current that > have been done and largely glossed over. Dont forget that -current and > -stable diverged at 2.0.5 release. They have been diverging so much that > backporting stuff from -current into -stable is starting to consume a > non-trivial amount of effort. THAT'S when you do a side release; but numbering it higher just to number it higher is a bad thing. > An interesting point: If the -stable branch was not consuming the amount > of maintainence time that it has been, we'd most likely _have_ 4.4Lite-2 > and PCMCIA integration, as well as a greatly debugged vm, vfs and kernel. Yes; I agree that splitting the maintenance from the developement is needed. Having people like John, and David, et al spending time back-porting is a waste of their talents. > Also, dont forget that things like FS layering, VFS cleanups, etc are being > put off because of the amount of effort being diverted to maintaining the > older code trees. Since these are very dear to your heart, I'd expect > you'd be the last person suggesting diverting more effort away from what > might have been spent looking at the changes you want to make. God forbid! 8-). No, I think that if an intermediate release occurs, it should be a sub-point-release; that's all I'm saying. Jacking up the version number makes you want to jack up the creeping features, and that's a *bad* thing. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.