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 _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel