Date: Mon, 23 Feb 1998 08:44:22 +1030 From: Greg Lehey <grog@lemis.com> To: "Jordan K. Hubbard" <jkh@time.cdrom.com>, Nate Williams <nate@mt.sri.com> Cc: Terry Lambert <tlambert@primenet.com>, current@FreeBSD.ORG Subject: Re: More breakage in -current as a result of header frobbing. Message-ID: <19980223084422.20994@freebie.lemis.com> In-Reply-To: <27525.888172295@time.cdrom.com>; from Jordan K. Hubbard on Sun, Feb 22, 1998 at 10:31:35AM -0800 References: <199802221752.KAA24429@mt.sri.com> <27525.888172295@time.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 22 February 1998 at 10:31:35 -0800, Jordan K. Hubbard wrote:
> Nate Williams wrote:
>> We can't have it both ways. Either we have an *enforced* policy of
>> actually punishing offenders (which may offend them and cause them to
>> run away), or we don't have any policy at all and so claiming to have
>
> I'd rather not have a policy based on punishment. We're supposed to
> be doing this for fun and the joy of making a good OS, and hitting
> people with sticks is not conducive to that.
Agreed. But a policy based on punishement isn't the same thing as a
policy which includes punishment in exceptional circumstances.
We've seen a lot of llamas, Terry-bashing and so on in this
discussion, but we don't seem to be any closer to a clear policy on
how to commit things. I made a suggestion about one possibility,
expecting people to tear it apart. Instead, they turned and chased
Terry, obviously a more satisfying activity.
Back to the original subject, guys. I proposed the following
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".
None of this should replace basic testing, of course (build it and
execute it, confirm it doesn't fall over immediately in every case).
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?19980223084422.20994>