> If you're going to > insist Insisting on nothing. Just have no way to do so.
> that people make assumption about your setup because you aren't > interested in describing it, then expect misleading answers. Certainly there will always be such a risk. The matter is how much. Certainly operating on incomplete data involves making assumptions. And, again (<[EMAIL PROTECTED]>), it is what people are generally pretty good at. Depending on responder's skill, error rate may be pretty low, to negligible. Far less than the rate of making assumptions directly contradicting details already supplied in report, assuming what one can trivially rule out by looking at such a details. Can easily recall (and, with a little bit more work, find in archives of mail concerning another package) at least 1 such case. > MUCH more aware of what assumptions they are making and performs > sanity checks on those assumption as they go. Note that that does not mean completely refusing to make assumptions. And these sanity checks even do not necessarily mean requesting more data. > because you aren't > interested in describing it As already wrote (<[EMAIL PROTECTED]>), this is normally not even the main reason. It is much more often that it is the responders who directly object to describing. And certainly would rather never receive such an objections, make it a law that one can post as much details as deems reasonable. > You seem quite sure about how much work it takes for me to write > different types of replies. Interesting. Nothing magic. Used and using to do a similar job on other packages. > Right, instead of ignoring them, we ask question The initial point was that asking like that was not only unnecessary, but could easily make answering pointless, worthless. Would rather receive quite different reply, and on request will post a sample. And if that was impossible, in that particular case even ignoring the report (for time just enough to write [not a bug] followup) was better. > Guessing what the > other end meant is practically *banned* in many IETF protocols "Handled gracefully" was humorous analogy, not a reference to model deemed adequate. So considering RFC contents in that much detail is just not relevant. Certainly (IETF) protocols described there are intended to run on pretty dumb entities, ones not even remotely capable of (again) "operating on incomplete data". _______________________________________________ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make