Date: Wed, 21 Apr 1999 20:50:15 +0100 (BST) From: Doug Rabson <dfr@nlsystems.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Peter Wemm <peter@netplex.com.au>, Matthew Reimer <mreimer@vpop.net>, freebsd-current@freebsd.org Subject: Re: solid NFS patch #6 avail for -current - need testers files) Message-ID: <Pine.BSF.4.05.9904212046460.85882-100000@herring.nlsystems.com> In-Reply-To: <199904211931.MAA07688@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 21 Apr 1999, Matthew Dillon wrote: > :I wonder if it would be too radical to suggest that the release cycle for > :4.0 be *much* shorter than the 3.0 cycle. Maintaining two branches gets > :worse and worse as time goes on and it just becomes a waste of programmer > :time. If we are reasonably careful with the 4.0 tree, I think a 4.0 > :release could be branched off it after 3.2 or maybe 3.3. > : > :It seems to me that merging a complex set of changes (such as the VM fixes > :or the new-bus work) from 4.0 to the 3.x branch would tend to produce a > :system which was less stable than the 'natural' environment for the > :software which is being merged across. > : > :-- > :Doug Rabson Mail: dfr@nlsystems.com > :Nonlinear Systems Ltd. Phone: +44 181 442 9037 > > I think the existing release schedule is pretty good. Any faster and > we might as well not have two branches at all. We really need a > -current branch in order to make and test radical changes, and the > companies & people who use FreeBSD need a -stable branch to keep > production boxes up to date without having to bet the farm. > > We already have the ability to shortcut certain things simply by > copying them from -current to -stable wholesale after we've determined > their stability under -current. The issue here really is safety. I > know some of you really want some of the things in -current to be > backported into -stable more quickly, but you have to be patient. We > can't compromise -stable's stability by acting too quickly. I totally agree about not wanting to compromise the stability of our release branch. However as the codebases diverge (and 3.0 diverged pretty massively from 2.2) it will get harder and harder to merge significant improvements across from the development branch without compromising the stability which we are trying to maintain. All I'm saying (I think) is that we shouldn't allow the 4.0 release cycle to stretch out to 2 years like the 3.0 cycle did (discounting 3.0 as a beta release). -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9904212046460.85882-100000>