Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
To: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
Cc: cygwin AT cygwin DOT com
Subject: Re: Perl 5.7.2
References: <3BC1CF2E DOT 7177 DOT 33050F17 AT localhost> <3BC1B8C0 DOT C1E58D08 AT rowman DOT com>
	<20011008115635 DOT A18826 AT redhat DOT com>
	<5 DOT 0 DOT 2 DOT 1 DOT 2 DOT 20011008123354 DOT 00b186b0 AT sen-mail DOT gtri DOT gatech DOT edu>
	<upu7yoxmz DOT fsf AT yandex DOT ru> <006501c15093$a36abae0$0200a8c0 AT lifelesswks>
From: Roman Belenov <rbelenov AT yandex DOT ru>
Date: 09 Oct 2001 13:20:04 +0400
In-Reply-To: <006501c15093$a36abae0$0200a8c0@lifelesswks>
Message-ID: <ug08tp3uj.fsf@yandex.ru>
Lines: 78
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

"Robert Collins" <robert DOT collins AT itdomain DOT com DOT au> writes:

> ---- Original Message -----
> From: "Roman Belenov" <rbelenov AT yandex DOT ru>
> To: "Ken Thompson" <ken DOT thompson AT gtri DOT gatech DOT edu>
> 
> 
> > Ok, let's stop quarreling and return to the facts. On my system
> > debugging with cygwin-1.3.3-2 is also not possible - debuggee receives
> > unknown signals before reaching main(). I reproduced it on the empty
> > program (after encountering on the real one). It is indeed a
> 
> Any program? or perl programs? Are you running bleedperl as John is?

Empty C program - main(){}

--- bug classification read and skipped

> The order I listed the categories above in is important: a category 4
> bug will NEVER be fixed by a cygwin developer. If it is, then it
> actually was a category 3, or 2..

So it means that cygwin is destined to be buggy - my experience (not
with cygwin) says that there are usually many bugs that require
significant efforts to be reproduced still they can affect many users
in certain circumstances.

> The amount of work needed on the part of the fault reporter increases
> >From 1 thru 4. If you report a bug and it's a 1, the report may be all
> thats needed, but if it's a 4 expect to learn gdb, and cygwin's source
> before it will get fixed.

Sorry, but usually users don't have enough time or experience to fix
bugs themselves, it's a job of developers. In case of open source
software users just don't have right to demand anything from
developers, but the dinstinction between users and developers remains
the same (of course, anybody can volunteer to switch from being a user
to being a developer, but not anyone would like to do it).

> This is not a matter of policy, or choice, or resources, its a simple
> matter of fact. Every software project acts like this: if a bug is non
> reproducible, then the onus is on the submitter to solve the bug
> AND/OR answer all questions from the developers about the bug - if
> they are putting it in my category 3.

So bugs in your category 4 will persist until some user will debug it ?
It makes quality of software product depend too much on its users.

> What does all of this rant mean for *you* on the cygwin list?
> 
> If you report a bug, and get given suggestions for debugging it, then in
> the opinion of the person making the suggestion, it is (in my category
> system) a 4 or possibly a 3. At this point, you have two choices:
> a) Ignore the bug. Go do something else. Don't whine, don't post about
> how it doesn't occur back a version in the hope that the bug will
> magically become easier for us to solve: We've already checked the code,
> and the changelog for obvious related info.

Well, in this particular case information that the bug doesn't exist
in the previous version should be helpful for developers since they
can't reproduce the bug. And amount of bug reports should be helpful
because it shows how widespread are the system configurations with
buggy behaviour and so may lead to understanding of the reason behing
it. It's not much, but it's still a bit of potentially useful
information.

> b) Follow the suggestions. Ask for help on following the suggestions.
> The bug will either become obvious to the developers during the ensuing
> dialogue, or you will find the fault, and be able to identify it
> precisely rather than generally, which usually gives the developers
> enough detail to create a test case themselves, at which point it
> becomes a 3, and you *may* get let off the hook.

Ok, I usually try to do it if the efforts required are reasonable from
my point of view.

-- 
 							With regards, Roman.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/