From owner-freebsd-stable Mon Jun 8 08:14:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA29932 for freebsd-stable-outgoing; Mon, 8 Jun 1998 08:14:51 -0700 (PDT) (envelope-from owner-freebsd-stable@FreeBSD.ORG) Received: from gateman.zeus.leitch.com (gateman.zeus.leitch.com [204.187.61.193]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA29515 for ; Mon, 8 Jun 1998 08:13:30 -0700 (PDT) (envelope-from woods@tap.zeus.leitch.com) Received: from zeus.leitch.com (tap.zeus.leitch.com [204.187.61.10]) by gateman.zeus.leitch.com (8.8.5/8.7.3/1.0) with ESMTP id LAA29109 for ; Mon, 8 Jun 1998 11:12:51 -0400 (EDT) Received: from brain.zeus.leitch.com (brain.zeus.leitch.com [204.187.61.32]) by zeus.leitch.com (8.7.5/8.7.3/1.0) with ESMTP id LAA20144 for ; Mon, 8 Jun 1998 11:12:55 -0400 (EDT) Received: (from woods@localhost) by brain.zeus.leitch.com (8.8.8/8.8.8) id LAA16030; Mon, 8 Jun 1998 11:12:55 -0400 (EDT) (envelope-from woods@tap.zeus.leitch.com) Date: Mon, 8 Jun 1998 11:12:55 -0400 (EDT) Message-Id: <199806081512.LAA16030@brain.zeus.leitch.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: woods@zeus.leitch.com (Greg A. Woods) To: freebsd-stable@FreeBSD.ORG Subject: Re: Matt Behrens: Re: kernel compile problem 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 References: <199806052348.JAA10962@gsms01.alcatel.com.au> X-Mailer: VM 6.45 under Emacs 20.2.1 Reply-To: freebsd-stable@FreeBSD.ORG Organization: Planix, Inc.; Toronto, Ontario; Canada Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ 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 > >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 Planix, Inc. ; Secrets of the Weird To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message