From owner-freebsd-current Tue Feb 26 20: 9:32 2002 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 3E1CA37B400; Tue, 26 Feb 2002 20:09:28 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g1R49Qi36990; Tue, 26 Feb 2002 21:09:27 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g1R49PL30775; Tue, 26 Feb 2002 21:09:26 -0700 (MST) (envelope-from imp@village.org) Date: Tue, 26 Feb 2002 21:09:05 -0700 (MST) Message-Id: <20020226.210905.11678065.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) From: "M. Warner Losh" In-Reply-To: References: X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: Robert Watson 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