Date: Sat, 21 Feb 1998 14:38:03 +1030 From: Greg Lehey <grog@lemis.com> To: "Jordan K. Hubbard" <jkh@time.cdrom.com>, John Birrell <jb@cimlogic.com.au> Cc: current@FreeBSD.ORG Subject: Re: More breakage in -current as a result of header frobbing. Message-ID: <19980221143803.31160@freebie.lemis.com> In-Reply-To: <23061.888029515@time.cdrom.com>; from Jordan K. Hubbard on Fri, Feb 20, 1998 at 06:51:55PM -0800 References: <199802210245.NAA06439@cimlogic.com.au> <23061.888029515@time.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980221143803.31160>