From owner-freebsd-stable Thu Jun 6 11:58:30 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA25592 for stable-outgoing; Thu, 6 Jun 1996 11:58:30 -0700 (PDT) Received: from iago.ienet.com (iago.ienet.com [207.78.32.53]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA25587; Thu, 6 Jun 1996 11:58:28 -0700 (PDT) Received: from brutus.ienet.com (brutus.ienet.com [207.78.32.152]) by iago.ienet.com (8.7.5/8.7.3) with SMTP id LAA03133; Thu, 6 Jun 1996 11:57:11 -0700 (PDT) Message-ID: <31B72B95.1FD5@ienet.com> Date: Thu, 06 Jun 1996 12:03:49 -0700 From: Terry Lee Organization: Internet Design Group X-Mailer: Mozilla 3.0b4 (Win95; I) MIME-Version: 1.0 To: John Polstra CC: jkh@time.cdrom.com, nate@sri.MT.net, stable@freebsd.org, committers@freebsd.org, scanner@webspan.net Subject: Re: Status of -stable References: <199606061536.IAA00209@austin.polstra.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Yes, I think John has a good point. It would be nice if -stable stuck around as a bug fix/new device driver tree even if it's not intended for release at all. I'm not saying that you should do this or that, just expressing that the -stable branch is very valuable in userland if only for a bug fixes and new device drivers. Cheers, Terry John Polstra wrote: > Well, I liked -stable too! Are you sure you're not over-reacting to > the recent nightmare? That pesky post-traumatic stress syndrome thing? > Hey, in time, the night sweats and flashbacks will pass. :-) > > It seems to me that -stable wasn't a big source of problems until this > mega-commit thing happened. OK, so, we've learned that you can't do > wholesale merges of every little thing into -stable. Fine. > > But what was the problem with the way we used it up until then? My view > of it was that, when a person would commit a bug fix to -current, he > would consider whether it should also go into -stable. Depending on the > nature of the change, it might go into -stable immediately, a few weeks > later, or never. > > It's a bit of a pain to merge change into -stable, granted, because > you have to think about each file, and consider what should get > merged and what should not. But isn't making judgements about > individual cases an essential element of a so-called stable release? -- I N T E R N E T Terry Lee, Technical Director D E S I G N 611 W. 6th St., Ste. 3201, Los Angeles, CA 90017 G R O U P 213.488.6100 voice 213.488.6101 fax http://www.mall.net mailto:terryl@ienet.com