On Tue, 26 Feb 2002, Garance A Drosihn wrote:
> I think the main issue here is how long the real repository can be
> "locked" while waiting for some change to show up. If work can keep
> going into the main repository, then what does anyone care if someone is
> tracking their own personal work using CVS, or perforce, or a bunch of
> home-grown shell scripts?
I think the answer varies a great deal by the work that's being done.
Suppose it's an implementation of mandatory access control on FreeBSD.
Would it be reasonable for me to request that anyone who is interested in
doing MAC on FreeBSD talk to me first before starting, so we can sync up
and make sure we're coordinating, even if it's going to take 16 months to
implement? Probably. Especially given that we'll probably end up
investing at least four man years (probably more) developing it, meaning
that people are unlikely to want to replicate that work when they could
just wait :-).
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.
Imagine it's an initial port to IA64. If someone has announced they're
working on it, you might expect people who would like to assist to
checkpoint, and even wait a couple of months if substantial work has been
done, before cutting it from scratch.
Imagine it's an announced set of patches to clean up some #define's in a
single C file. That's probably worth a couple of days wait to see if
they're serious about doing it, since it's unlikely to stand in the way of
much, but probably not much more.
This suggests three rules of thumb that might make sense:
(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...".
(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
[EMAIL PROTECTED] NAI Labs, Safeport Network Services
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
