Date: Tue, 26 Feb 2002 21:09:05 -0700 (MST) From: "M. Warner Losh" <imp@village.org> To: rwatson@FreeBSD.ORG Cc: drosih@rpi.edu, julian@elischer.org, current@FreeBSD.ORG Subject: Re: Discussion of guidelines for additional version control mechanisms (fwd) Message-ID: <20020226.210905.11678065.imp@village.org> In-Reply-To: <Pine.NEB.3.96L.1020226222533.38595N-100000@fledge.watson.org> References: <p05101402b8a1ffde0552@[128.113.24.47]> <Pine.NEB.3.96L.1020226222533.38595N-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <Pine.NEB.3.96L.1020226222533.38595N-100000@fledge.watson.org>
Robert Watson <rwatson@FreeBSD.ORG> writes:
: > 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.
:
(4) Locks that maintainers assert over their parts of the tree.
This is usually only used for device drivers, and these locks
tend to expire relatively quickly in the scheme of things, but
which may lasts for a while. Here we have the concept of a
maintainer timeout too. Eg, if the maintainer blows you off for
more than a week or two, then you can go ahead with the commit.
The lock tends to evaperate after a couple of months of this.
When well publicized, this works well. When not well
publisized, this works less well.
Warner
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?20020226.210905.11678065.imp>