Date: Tue, 26 Feb 2002 22:08:54 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.ORG> To: Julian Elischer <julian@elischer.org> Cc: Garance A Drosihn <drosih@rpi.edu>, current@FreeBSD.ORG Subject: Re: Discussion of guidelines for additional version control mechanisms (fwd) Message-ID: <Pine.NEB.3.96L.1020226220321.38595M-100000@fledge.watson.org> In-Reply-To: <Pine.BSF.4.21.0202261846230.97278-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 26 Feb 2002, Julian Elischer wrote: > > On the other hand, you could easily argue that the expectations might be > > much lower for smaller pieces of work. For example, the move to td_ucred > > required a substantial amount of infrastructure, but the patches > > themselves are relatively sane and small. Once the pieces are all in > > place (which they mostly are), knowing that someone has a lock on it is > > probably worth a "are you still working on this" followed by a wait of a > > week or two to see if it turns up before forging ahead. > > Bad choice.. > p->p_ucred => td->td_ucred in istself requires almost no > infrastracture change, the bulk of the commit is trivial, (AND STILL NOT > COMMITTED) and waiting for weeks on such a trivial thing before being able > to proceed on some interlocking piece is foolish. I was referring to its dependency on KSE. > > (1) The timeout begins when contention occurs, of the lock has been > > declared. This means that if you seriously intend to do some work, > > you can say "I'm going to do the work", but you don't risk losing the > > lock until someone comes to you and says "Hey did you ever...". > > Locks shouldn't be unilateral and they shouldn't last more that the > amount of time that it takes to import a change and get it stable. i.e. > maybe a week or so at most. Someone used KSE-II as an example.. They > said I had a 2 month lock (??) I don't know where they got that idea > from.. I had a vague concensus that maybe things may be broken for a DAY > OR TWO. while the commit was happenning. I the end it was about right. So it sounds like we disagree on what a lock is. My interpretation of the word lock was that it refered to ownership of a task. For example, we gave you ownership of the general task of pushing KSE forwards. This means that if someone turns up and says "I have SAs, I did it entirely differently, I'm going to commit it now" we might say "Hold just a second there". We'd probably say that even if they said "I have SAs, I did them entirely the same way, I'm going to commit it now". The model I'm thinking of is really about someone saying "I'm going to go work on <foo>. Please don't work on <foo> without talking to me first, because it would be a shame to waste all my time, or all your time, by not coordinating." I consider this to be more of a lock based on intention than a "hard lock". It's about avoiding duplicate work, trodden on toes, etc. It might be akin to claiming a task from a public task list. The lock you're describing appears to be more of a source tree lock: no one touch this section of the source tree, because someone is doing work relating to it in another tree. For example, someone might ask that no one touch the USB code for a few days while a change is phased in. Or that people expect the tree to break for a few days as a large API change is phased in and the final integration tested. This is not the kind of lock I'm talking about. 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.1020226220321.38595M-100000>