X-Spam-Check-By: sourceware.org
Message-ID: <44C5F25A.2020900@equate.dyndns.org>
Date: Tue, 25 Jul 2006 11:28:42 +0100
From: Chris Taylor <chris AT equate DOT dyndns DOT org>
Reply-To: cygwin AT cygwin DOT com
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
CC: joachima AT netacquire DOT com
Subject: Re: Why are Windows paths broken in make 3.81?
References: <9c2aabaf0607211629u4e29ffa1w5f09b3d8e5a923fc AT mail DOT gmail DOT com> <e9rrqr$6ei$1 AT sea DOT gmane DOT org> <44C1796F DOT 50308 AT netacquire DOT com> <20060722222244 DOT GB18054 AT trixie DOT casa DOT cgf DOT cx> <44C4FF71 DOT 6050505 AT netacquire DOT com> <20060724184240 DOT GB21218 AT trixie DOT casa DOT cgf DOT cx> <44C5252F DOT 5040201 AT netacquire DOT com> <20060724201338 DOT GC23671 AT trixie DOT casa DOT cgf DOT cx> <44C53AED DOT 9070306 AT netacquire DOT com>
In-Reply-To: <44C53AED.9070306@netacquire.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

Joachim Achtzehnter wrote:
> 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.

The problem was that you didn't follow the guidelines on:

Problem reports:       http://cygwin.com/problems.html

I don't recall seeing a cygcheck.out, and you certainly didn't break it 
down to a simple testcase..
This means that the maintainers (as well as the rest of us) have no real 
clue as to where to begin to replicate the behaviour so that they can 
bring their collective might to bear on it.


>>> 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.

Even in cases where it might, what I've mentioned above applies, 
otherwise it's an incomplete bug-report that just clogs things up and 
makes it difficult to track down solutions..

> 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?

Testcase, combined with gdb, perhaps?

>> 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
>> etiquette.

> 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.

> Thanks,

> Joachim


Anyway.... Hopefully things are about done with that now..

EqUaTe

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/