This is the mail archive of the
mailing list for the Cygwin project.
Re: add -debuginfo packages
On Fri, 21 Aug 2009, Christopher Faylor wrote:
> On Fri, Aug 21, 2009 at 10:28:13AM -0500, Brian Ford wrote:
> >On Thu, 20 Aug 2009, Christopher Faylor wrote:
> >>How many people here are capable of firing up a debugger to decode
> >A lot more if they don't have to go through the pain of downloading
> >source code and figuring out how to correctly build the package. You'd
> >get better bug reports faster I think. How many times have you
> >requested a more refined test case because you didn't want to have to
> >build perl in order to debug it?
> You're incorrect in thinking that I'll stop asking for refined test
> cases just because perl debugging info is available. I'm perfectly
> capable of building perl myself if I thought it was necessary. I am
> even capable of debugging perl.
I didn't mean to imply either of those things; poor wording choice on my
part I guess.
> I don't want to do any of that.
That was my point; neither do I. But having that debug info readily
available to me would make it much simpler to produce one of those STCs.
Often, one such simple clue is enough to distill the necessary STC.
> I want the maintainers to be capable enough to narrow down a test case
> to help spread the burden of debugging around.
I agree, but I would like to spread it around even further by making it
simpler for capable users under time constraints to be more productive.
> I've already made the cost benefit analysis of the .5% of people who
> would find this useful
I would expect that to be closer to 5%, but anyway...
> vs. the amount of time it would take me to implement in upset and
> potentially setup.exe,
I failed to consider the volunteer impact required to support these two in
> the amount of time it would take package maintainers (like me) to
Especially with cygport, I wouldn't expect that to be much.
> the amount of extra disk space it would take on sourceware, the amount
> of extra net bandwidth that would be consumed by mirror traffic and the
> amount of extra cygwin mailing list "do I need this?" traffic we'd see.
> I appreciate the thought that went into the proposal but I don't think
> this is something that we want to waste limited cygwin volunteer
> resources to support.
Yes, you clearly expressed that opinion the last time this topic was
raised so I already understood your position. I just disagree with the
Staff Realtime Software Engineer
VITAL - Visual Simulation Systems
the best safety device in any aircraft is a well-trained crew...
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple