Date: Tue, 26 Feb 2002 22:29:05 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.ORG> To: Garance A Drosihn <drosih@rpi.edu> Cc: Julian Elischer <julian@elischer.org>, current@FreeBSD.ORG Subject: Re: Discussion of guidelines for additional version control mechanisms (fwd) Message-ID: <Pine.NEB.3.96L.1020226222533.38595N-100000@fledge.watson.org> In-Reply-To: <p05101402b8a1ffde0552@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 26 Feb 2002, Garance A Drosihn wrote:
> That would be me...
>
> I meant "lock" in the sense of expecting no one to make any major
> changes in the same area of code. I seem to remember you asking for
> such a "lock" (to use the term loosely) in July, and the KSE work going
> in around August or so. My memory is admittedly vague. My point was
> you explicitly asked for permission to go ahead with that work, even
> though (at the time) we were shooting for a release date in November.
>
> I don't mean the period of time that -current was actually unstable, but
> the amount of time that other developers were asked to stay away from a
> major section of code.
So it seems to me we have at least three types of locks now, actually:
(1) Locks protecting specific bits of code in the tree; for example,
during a merge effort that requires several commits over a few days to
a week. This should be very short.
(2) Locks that protect a subsystem from substantial changes, such as a
request to not change vm_mmap.c for a week or two during a rewrite:
small changes might be fine, but larger ones would substantially
hamper the work. These should also be short.
(3) Locks that protect a particular task on a particular piece of code.
These simply assert "Don't do this particular activity, becasue I'm
doing it". My feeling is that these should be permitted to be long,
and are in fact desirable. They wouldn't protect against changes in
the subsystem, just identical changes in the subsystem, subject to
common sense.
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
robert@fledge.watson.org NAI Labs, Safeport Network Services
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?Pine.NEB.3.96L.1020226222533.38595N-100000>