Re: reporting requirements
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
Re: reporting requirements
No one is getting paid, Unfortunately, the attitude, once established here, nearly inevitably spreads to other situations, even exactly those of paid support. It would be nice to be able to nuke it in all assigned to paid support, to automatically force everybody manifesting it to go back to unpaid occupations, with free / open source software or other. Unfortunately, no way to ensure that is known. expend the effort to do so This tries to represent things as if some terrible effort is required. Generally it is not so. Instead, it requires much less work than writing the voluminous, useless (and hurting - to some, not me) reply that started the thread. For exactly the same reason: it is inherent ability of humans. way things work Or, more often, do not work. you learned a lot more than Acceptable only with `:-)': again, learning about tool internals (let alone misfeatures or even bugs) is not desirable at best. Agree that, personally, normally would have checked more before posting. Why it was unacceptable to do that in that particular time with that particular issue is improper here. My point is that users getting in such situations are inevitable time after time, and that such a behavior of users should be allowed, handled gracefully (as many RFC say). ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: reporting requirements
On Fri, Aug 22, 2008 at 1:40 PM, Ilya N. Golubev [EMAIL PROTECTED] wrote: ... expend the effort to do so This tries to represent things as if some terrible effort is required. Generally it is not so. Oddly enough, that's not my experience. When someone doesn't provide enough data, the responder has three options: A) write a completely general reply. For any non-trivial question, this quickly becomes impossible. B) make assumptions. If the assumption is wrong, then the answer is worse than useless, at it starts the search in the wrong direction. C) ask for more data. In my experience, the biggest difference between someone good at debugging and someone so-so at debugging is that the former person is MUCH more aware of what assumptions they are making and performs sanity checks on those assumption as they go. If you're going to insist that people make assumption about your setup because you aren't interested in describing it, then expect misleading answers. Instead, it requires much less work than writing the voluminous, useless (and hurting - to some, not me) reply that started the thread. Huh. You seem quite sure about how much work it takes for me to write different types of replies. Interesting. ... Agree that, personally, normally would have checked more before posting. Why it was unacceptable to do that in that particular time with that particular issue is improper here. My point is that users getting in such situations are inevitable time after time, and that such a behavior of users should be allowed, Right, instead of ignoring them, we ask question to help narrow down the problem. handled gracefully (as many RFC say). Heh. Many of those RFCs also specify error responses to send when the other end does something incorrect/non-compliant. Guessing what the other end meant is practically *banned* in many IETF protocols due to the horrible experiences of some early protocols. I recommend Paul Vixie's published papers about BIND and how the handle gracefully mentality resulted in security holes in DNS. Philip Guenther ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
reporting requirements [Re: does not rebuild Makefile.in]
As for the original (not of make) issue, confirming my [not a bug] posted on Wed, 20 Aug 2008 22:49:44 +0400 ([EMAIL PROTECTED]). As for attitude expressed in your reply of Wed, 20 Aug 2008 02:57:21 +0400 (MSD) ([EMAIL PROTECTED]), it is pretty widespread in many free sofware mailing lists, fora, so commenting on it. You wrote: Nice way to be helpful Followed it with assorted what was this, what was that questions, followed by Are we supposed to just *guess*??! This may seem justified, and is at least understandable. And complying with all of this takes in most cases even more work than isolating (and even possibly fixing) the bug entirely on one's own. So the posting becomes pointless. Sadly, with this particular software issue it was exactly what happened. The lesson? In [[The Moon Is A Harsh Mistress]] (by Robert A. Heinlein) even a machine Mike was designed, even before augmented, to answer questions tentatively on insufficient data like you do Mike was designed to operate on incomplete data. People are generally able to do that pretty well. This is reason for users posting issues (including me) to hope ones replying to exercise this ability, rather than request users to supply complete data ;-) . You'd rather make people Posted message by itself makes people do nothing. Also note the detailed bug description (of Wed, 20 Aug 2008 22:43:38 +0400 ([EMAIL PROTECTED])) on [EMAIL PROTECTED] (and proposed fix (of Wed, 20 Aug 2008 22:43:53 +0400 ([EMAIL PROTECTED])) on [EMAIL PROTECTED]). The bug is shown to be pretty portable, its manifestation thus does not depend on (answers to) most of your [what was?] questions. Trying random automake input ((source) package) made perfect sense. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: reporting requirements [Re: does not rebuild Makefile.in]
On Thu, 2008-08-21 at 23:50 +0400, Ilya N. Golubev wrote: This may seem justified, and is at least understandable. And complying with all of this takes in most cases even more work than isolating (and even possibly fixing) the bug entirely on one's own. So the posting becomes pointless. Yes. That's a GOOD THING, and exactly what Philip intended. People reading this list are volunteers. No one is getting paid, and in fact most people are helping here to the detriment of other things they could be doing for their jobs, families, health, recreation, etc. As such, it's incumbent upon the people asking for help to not abuse this generosity. That means making an honest, _serious_ effort to solve problems yourself _before_ asking for help. By asking for all this information and requiring people to provide it, we are ensuring not only that we can actually help them, but also that they've made enough of an effort to fix their own problem that it's worthwhile for us to take time from whatever other important things we're doing to assist them. You're exactly right that half the time the effort they put in to collecting all this data leads them to find the problem themselves, and then they can delete the email they're writing to the list. That's the best possible outcome for everyone; it's what we hope for. Yes, of course, we are smarter than machines and we are able to infer a lot from less data, if we want to expend the effort to do so. But we don't want to expend that effort. We have no reason to make that effort to help people who won't first spend some effort to help themselves. It may sound harsh, and some people will put it more bluntly than others, but that's the way things work in open source software. You aren't paying for support with money, but that doesn't mean it's free. Instead you have to pay for it with effort. Plus, look at it this way: by making that effort and fixing your own problem you learned a lot more than you would have if we'd just given you the answer :-). ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
