Date: Tue, 26 Feb 2002 19:24:50 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: Robert Watson <rwatson@FreeBSD.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.BSF.4.21.0202261911580.97278-100000@InterJet.elischer.org> In-Reply-To: <Pine.NEB.3.96L.1020226220321.38595M-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 26 Feb 2002, Robert Watson wrote: > > 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". ] Sore point: phk: "I've got DEVFS, I did it differently it's much better than tho old fully working one. I'm going to check it in now" core: "OK" phk: Ok I deleted parts of the old devfs so that it's now totally uselss. [2 years pass, system has no useable devfs..] phk: ok here's my devfs.. of course it doesn't work as well as the old one but it's much better. [checks in non working code] oops: spends 3 months getting bugs ironed out. Completed devfs still doesn't do (by design) as much as the old one.. > > 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. But you see I am doing KSE despite the fact that other people are changing and improving code that is central to KSE all the time. When it happens I integrate the change, modify it to handle threads and move on. Even John does this but it's OTHER PEOPLE who keep leaping up and demanding that things not be committed becasue it may give john a headache.. well, his "lock" is tooooo long (and anyhow it's not a lock. It's just what he's working on. it can't be allowed to screw over everybody. > > 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.BSF.4.21.0202261911580.97278-100000>