Re: [Monotone-devel] [PATCH] mtn automate set_option

[Nathaniel J. Smith]

On Sat, Dec 23, 2006 at 01:22:21AM +0100, Thomas Keller wrote:
> Don't get me wrong, but how is he supposed to know that?

Well, because I just told him :-).  Maybe he will find the information
useful, maybe not.  I guess there are a few possible outcomes.  Maybe
neither Ben nor anyone else actually knows what use such a feature
would be, in which case we learn that it's not worth spending time on
before any more resources are sunk into it, and record that fact in
the mailing list archives.  Or perhaps we will learn that it is
useful, but in such rare and tenuous cases that we could get 100 times
the benefit by spending the same resources working on some other
feature, and we will all get a nice lesson on why the concept of
"opportunity cost" is so useful.  Or perhaps we will learn that it is
actually a great idea, and will be convinced to spend more time on it
(and the reasons for _that_ will be recorded in the mailing list
archive too).  Or perhaps we will learn that it isn't such a great
idea as is, _but_ discover some other similar feature that none of us
even thought of before, that is really useful.

...Or maybe it will simply provoke a general discussion of resource
allocation in a volunteer project, which is always a tricky topic :-).

(Also note that I didn't say "this patch sucks and you should print it
out so you can feed it to your dog"; I was just explaining why I was
nervous about investing my own time in it, and hoping to create useful
discussion.  If other people want to get it landed on mainline, then
I'm not likely to invest my time in stopping that either, unless it
were missing tests or had egregrious coding issues or something.)

> Maybe we should 
> start and explicitely name / comment certain things as "temporary, will 
> be replaced", so no manpower goes into that?

Maybe -- there was some discussion in the past of having a class of
"experimental" automate commands, that are second-class citizens in
the sense that they do not have compabitility guarantees, and should
eventually either be promoted tor be "real" automate commands, or else
removed.  Clients would have to take some affirmative action to
request access to such commands (like using 'automate_experimental' in
place of 'automate', or something).  No-one has written any
infrastructure for this, though it would probably not be too hard.

HTH,
-- Nathaniel