Date: Tue, 26 Feb 2002 18:55:09 -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.0202261846230.97278-100000@InterJet.elischer.org> In-Reply-To: <Pine.NEB.3.96L.1020226213043.38595L-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, Garance A Drosihn 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. Further more as td_ucred can be used almost everywhere p_ucred is used, and p_ucred is not going away, it could have been done piecemeal without any danger.. I could change one occurance of p_ucred to be td->ucred pehour over a 2 month period whenever I had a few spare cycles and the tree would be none the worse for it. > > (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. > > (2) The strength (timeout) of the lock depends on the level of investment > by the person holding the lock. That means if it's a trivial patch, > the time to break the lock is short, perhaps nil, but if it's a large > piece of work, there's the opportunity to say "Yes, it's a work in > progress, is that OK?", "Give me a week to finish it up", or "It's > going to take me a long time, why don't you take over", or in the > worst case "I'm doing it" followed by a timeout. > > (3) Common sense applies. > > It also suggests that there be a way to register intent and interest > relating to a topic. For example, I maintain a web page expressing intent > and on-going work regarding the TrustedBSD Project. It's linked from the > FreeBSD projects page. I've posted about it on lists. That suggests that > I have a relatively strong lock, for some definition of lock. It doesn't > preclude me from accepting contributions, soliciting contributions, etc. > It just means that if someone says "Ok, that's it, enough waiting, where > is it" I probably get a little more patience because people are aware the > work is on-going, before I get timed out and blown off. > > 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 > 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.0202261846230.97278-100000>