Date: Mon, 8 Jun 1998 11:12:55 -0400 (EDT) From: woods@zeus.leitch.com (Greg A. Woods) To: freebsd-stable@FreeBSD.ORG Subject: Re: Matt Behrens: Re: kernel compile problem Message-ID: <199806081512.LAA16030@brain.zeus.leitch.com> In-Reply-To: Richard Wackerbarth's message of "Fri, June 5, 1998 20:24:18 -0500" regarding "Re: Matt Behrens: Re: kernel compile problem" id <l03130300b19e494c0321@[208.2.87.10]> References: <199806052348.JAA10962@gsms01.alcatel.com.au> <l03130300b19e494c0321@[208.2.87.10]>
next in thread | previous in thread | raw e-mail | index | archive | help
[ On Fri, June 5, 1998 at 20:24:18 (-0500), Richard Wackerbarth wrote: ] > Subject: Re: Matt Behrens: Re: kernel compile problem > > At 6:48 PM -0500 6/5/98, Peter Jeremy wrote: > >On Fri, 05 Jun 1998 06:42:00 -0500, Richard Wackerbarth <rkw@dataplex.net> > >wrote: > >> That brings us back to the question of "Why?". Should the 2.2 branch > >>have been changed now? Perhaps this aspect should have been frozen until > >>we are preparing for a 2.2.7 release. > > > >I think this is backwards. These sort of changes should be made well > >in advance of any proposed release so that they can be adequately > >tested (and backed out if serious problems arise). Putting `major' > >changes in just before a release is almost always a bad idea. > > It this case, I disagree. First, this is the "stable" branch. > We are not supposed to be "debugging" features here. Perhaps you're confusing "stable" and "release". I think all Peter was trying to say was that if changes are to be introduced to the RELENG_2_2 branch then they should be introduced as soon as possible so that they can be "debugged". I agree that this is especially important for "major" changes, no matter how well tested and "stable" they may be in the -current branch. > Unlike "current", users should expect to be able to build from it > at all times. By introducing changes to the kernel which require a > change to the config tool, the building of kernels is broken for > users who do not have the full source and manually overcome the > dependancy that is not handled automatically for them. That's definitely not the impression I had. I expect the live branch to be exactly that, a *live* branch with ongoing changes and corrections. I do expect the *releases* from the RELENG_2_2 branch to be 100% stable though. The handbook is, of course, a little vague on this matter: FreeBSD-stable is our development branch for a more low-key and conservative set of changes intended for our next mainstream release. Changes of an experimental or untested nature do not go into this branch However as someone quite familiar with CVS development techniques, and also given the nature of any software change, I can assure you that planning a stable product release is an entirely different matter than simply trying to work on a development branch where only the most conservative and well tested (on other branches) changes are introduced. As a matter of fact I'd like to see release branches fork off from each development branch simply so that there's no conflict between the "release" activities and ongoing "development". However since I don't actually have anything to do with the FreeBSD repository, and esp. not with the release process, except as a user, well, I guess what I'd like to see doesn't really matter all that much. > If we wait until just before a new release, the window whereby > they cannot build is reduced since they will get the new binary of > the config tool soon. That's a really bogus argument. -- Greg A. Woods +1 416 443-1734 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806081512.LAA16030>