This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Why are Windows paths broken in make 3.81?

Christopher Faylor wrote:

I guess that means there is nothing more to discuss.

Agreed, except for the following.

On Mon, Jul 24, 2006 at 12:53:19PM -0700, Joachim Achtzehnter wrote:
Christopher Faylor wrote:
Well, you *could* expect a fix if you provided enough details.
Understood.  The question is, can there still be value in reporting
that a program crashes, even with minimal but potentially still useful
information?  I'm just asking and am genuinely interested in hearing
the developers' preferences.

No. Reports of "XYZ dies when I run a complicated program" are worthless unless the reporter is willing to help track down the problem.

I resent being mis-represented like this: The report mentioned a very specific error message and was about a change in behaviour from one version to the next. I accept your "No" answer though, you won't see similar reports from me in the future.

If this kind of less-than-ideal problem report is considered to be
always useless, which would come as a surprise to me because as a
developer I've seen many cases where a report like this is all that was
needed to highlight the problem,

I would be very very surprised if you were able to fix problems when someone just mentions that their program crashes when they do something complicated. If that really was the case then you would just have to say that to yourself before every release in order to fix problems.

The point is that nobody was *just* mentioning what you write here. First off, as I wrote above, this was about changed behaviour between one version and the next, presumably implying that only a (relatively) small portion of the source code had changed. It was about the most recently released version, i.e. there is a good chance the changes are still (relatively) fresh in the minds of the developers. Thirdly, there was a specific error message rather than a totally uninformative crash, suggesting that it might (possibly) ring a bell. None of this implied that the information provided would be sufficient (and I didn't count on it), but from my experience there was a reasonable, if small, possibility that it might.

I've certainly seen many cases where I just needed to see an error message like this in conjunction with having released a recent change to know immediately what went wrong. Obviously, it is just as likely that this doesn't help at all. In spite of the latter, I definitely want to see such reports from our customers as it can save time for both of us. If the provided info doesn't help one can always ignore it until more effort is put into providing more details. In any case, the last thing I can afford to do in such a situation is to accost my customer, but then I'm in a different situation from you on that point. :-)

If that really was the case then you would just have to
say that to yourself before every release in order to fix problems.

And how do I divine the error message?

I didn't take it out of context before and I am not doing so now.  I
trimmed the parts that I wanted to respond to, as is good internet

Trimming to the relevant parts is one thing, trimming (and rephrasing) to the point where the quote mis-represents what was written is another...

I was trying to get to the bottom of something that seemed like it could
be a bug.

If you hear more from me about the crash it will be with sufficient information to reproduce it without sending you several hundreds of thousands of lines of source code and makefiles.



work:   (
private:          (

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]