Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 18 Feb 2002 12:54:43 -0500 (EST)
From:      Robert Watson <rwatson@FreeBSD.ORG>
To:        Matthew Dillon <dillon@apollo.backplane.com>
Cc:        Poul-Henning Kamp <phk@FreeBSD.ORG>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG
Subject:   Re: cvs commit: src/sys/kern kern_time.c
Message-ID:  <Pine.NEB.3.96L.1020218125409.69361p-100000@fledge.watson.org>
In-Reply-To: <Pine.NEB.3.96L.1020218124159.69361o-100000@fledge.watson.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1020218125409.69361p-100000>