From owner-cvs-all Mon Feb 18 9:55: 1 2002 Delivered-To: cvs-all@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 79A9437B405; Mon, 18 Feb 2002 09:54:49 -0800 (PST) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id g1IHsiD83829; Mon, 18 Feb 2002 12:54:44 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Mon, 18 Feb 2002 12:54:43 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Matthew Dillon Cc: Poul-Henning Kamp , cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern kern_time.c In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In case you missed it, this was an e-mail to please not commit things that are known to be duplicated/in conflict with jhb's proc locking patch. Please do not commit the changes you have described. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services On Mon, 18 Feb 2002, Robert Watson wrote: > On Mon, 18 Feb 2002, Matthew Dillon wrote: > > > John seems to have patches for just about everything, but they're > > useless if he doesn't focus and start committing them. I am going > > to start comitting the simpler stuff, like the ucred stuff that is > > based on Julian's work (which John ought not to have patches for > > since it didn't exist two days ago). If we hit a conflict John can > > email me and we will work it out. > > With all do respect, I'd like to ask you to hold off for a couple of days > until John is back in communication again from his travel to/from BSDCon. > Over BSDCon he was talking about committing it within the next four days, > so I think everything is really just about ready and queued up. There's > no point in duplicating the work, and creating unnecessary conflicts for > him. With respects to the ucred work on the thread side: that's something > that John has had specifically in mind -- in fact, he initially described > the cached td_ucred model many months ago, and was waiting on KSE progress > to commit much of the use of it because of the presence of race conditions > until now (relating to interrupt handling). > > > Otherwise I won't be able to commit > > anything at all in any subsystem for the next year without first > > checking with John, which is rather silly. > > Coordinating work and commits is a prerequisite for working on a large > project, as I'm sure you know. When I start work on some piece of > security infrastructure, I check with the likely suspects before doing the > work so that we don't duplicate work, or tread on each other's toes. If > you're working on SMPng, then naturally you'll have to check with other > SMPng developers when doing the work. It's really not very hard, and it > can save everyone a lot of trouble. As you know, one of the larger goals > of the SMPng work was to allow people to work more effectively in parallel > through strong reliance on coordination and communication. > > 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 cvs-all" in the body of the message