From owner-freebsd-current Fri Feb 20 20:14:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA20953 for freebsd-current-outgoing; Fri, 20 Feb 1998 20:14:08 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA20895 for ; Fri, 20 Feb 1998 20:13:56 -0800 (PST) (envelope-from grog@lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.8.7/8.8.5) with ESMTP id OAA05029; Sat, 21 Feb 1998 14:38:50 +1030 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.8.8/8.8.7) id OAA15635; Sat, 21 Feb 1998 14:38:03 +1030 (CST) (envelope-from grog) Message-ID: <19980221143803.31160@freebie.lemis.com> Date: Sat, 21 Feb 1998 14:38:03 +1030 From: Greg Lehey To: "Jordan K. Hubbard" , John Birrell Cc: current@FreeBSD.ORG Subject: Re: More breakage in -current as a result of header frobbing. References: <199802210245.NAA06439@cimlogic.com.au> <23061.888029515@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: <23061.888029515@time.cdrom.com>; from Jordan K. Hubbard on Fri, Feb 20, 1998 at 06:51:55PM -0800 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 20 February 1998 at 18:51:55 -0800, Jordan K. Hubbard wrote: >> Jordan K. Hubbard wrote: >>> Yeah, no kidding. Since nobody seems to be build testing their >>> changes anymore I guess I'll just put this on the "indefinate >>> postponement" list. >> >> Come on, it's not that bad. My build is nearly complete, so I'll >> commit a fix to sys/time.h > > Yeah, but as Greg has already noted, it's been broken almost *every > day* for the last week or so. If it's possible for it to be any > worse, I'm not sure I want to know. :-) Maybe now's an appropriate time to come out with a thing that I've been meaning to propose for some time: Sure, living with -CURRENT means never knowing where your next install comes from, and people who complain about the situation justifiably get chewed out. On the other hand, though, one of the main reasons for having -CURRENT is to get code under development to as many techhies as possible so that bugs can be found more easily. There's a delicate balance here: - If people commit only perfect code, the result is -STABLE, not -CURRENT. While that doesn't sound bad in itself, it means significant delays to any commit. - If people commit only code which breaks a 'make world', nobody will ever get -CURRENT installed. Even if it only happens 50% of the time, it will frustate a large number of users to the point where they can't be bothered any more. The problem with both of these extremes is that they go contrary to the idea of -CURRENT. A good example of the problem is John Dyson's changes to the VM system. Before he commits them, he tests them. make world works. But almost invariably, the fixes break for somebody. For John, that means weeks of fiddling around to fix things. Finally he gets them fixed, and the system's the better for it. You could say "John should test his changes better before commiting them". But that's not always possible. The bugs don't break things for him. -CURRENT's there exactly for that. On the other hand, this kind of commit imposes a certain rhythm on the stability of -CURRENT. Before somebody commits a big change like that, the system is relatively stable. After the wrinkles have been ironed out, it's relatively stable again. In between, times can be rough. What I'm suggesting (finally!) is: Let's accept the fact that -CURRENT's stability fluctuates and try to influence the rhythm. One possiblity might be to say: - The first weekend in each month is the correct time for commiting big modifications that can potentially compromise stability for a while to come. - Any Sunday is the correct time for commiting smaller modifications that can potentially compromise stability for a few days. The advantage is that people can expect -CURRENT to be relatively stable on a Friday, and particularly stable at the end of a month. This is only a suggested implementation. I don't know how inconvenient it might be. Another alternative is the "heads up" approach--after a period of relative stability, somebody could say "I'm going to commit some changes to the frobulator which potentially impact stability. I'll do it tomorrow night unless I'm shouted down". Clearly this needs discussion. Go for it. Greg To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message