From: Kevin_Hendricks <khendricks@admin.ivey.uwo.ca>
To: gdb@sourceware.cygnus.com, patl@cag.lcs.mit.edu
Subject: Re: Preparing for the GDB 5.0 / GDB 2000 / GDB2k release
Date: Sat, 01 Apr 2000 00:00:00 -0000 [thread overview]
Message-ID: <21267.950023252.0@NO-ID-FOUND.mhonarc.org> (raw)
Hi,
>The SamL/H.J. patches fix the problem, as far as we can tell here.
>And those patches are not very large. Is it really so hard to put
>them in and fix the problem the Right Way later? The argument "we
>can't accept every hack" is pretty weak. You are not being asked to
>accept every hack, you are being asked to accept a single hack which
>addresses a very serious problem on a major platform.
>
>Just $0.02 from a developer who is tired of manually patching
>prereleases...
I second that motion whole-heartedly.
And while you are at it, why not fix gdb to actually work with ppc and actually
really and truly support a major platform (ppc) RIGHT_OUT_OF_THE_BOX god forbid!
I am so tired of fighting with non-working gdb on ppc that gdb has become next
to useless. I am now getting hangs with wierd thread errors when debugging
programs with Franz Sirl's gdb (and his is the *best* one I have found on ppc so
far).
I know this has been addressed before (but never to my satisfaction) but why can
patches I submit to the ppc kernel developers, patches to glibc, patches to gcc,
patches to xfree86, etc *all* be accepted without any further nonsense and
actually get done while all I ever hear from gdb for every patch that comes
through the lists is excuses (i.e. one of):
1. it has to be done right and since we don't have time to do it right
it can't be done (i.e getting working ppc linux support whether
integrated with rs600 support or not!)
2. patches need to be in the right FSF format or we can't except them
(what bullshit)
3. we can't use your patch you have not signed a damn release
(again why do none of the other FSF project require this).
I *never* hear these from any other project.
Why is gdb so different?
Why can't it open up it process of getting patches in?
Why is gdb development not geared to support Linux (any architecture) in any
reasonable manner?
So now we will have yet another new major gdb release without things working on
powerpc (expected!) or even x86 linux???.
No wonder people are forking gdb. It is the only way to get anything
accomplished.
Please explain to me why gdb development can't be more like the other major
projects out there who actually *gladly* accept patches?
Is this too much to ask?
Really?
Kevin
BTW: I want to make this one thing *clear*, I *greatly* appreciate all the hard
work the gdb maintainers do, the process is simply very very bad and needs to be
opened up and fixed like yesterday.
--
Kevin B. Hendricks
Associate Professor of Operations and Information Technology
Richard Ivey School of Business, University of Western Ontario
London, Ontario N6A-3K7 CANADA
khendricks@ivey.uwo.ca, (519) 661-3874, fax: 519-661-3959
next reply other threads:[~2000-04-01 0:00 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-04-01 0:00 Kevin_Hendricks [this message]
[not found] <389ECBAF.66013B07@cygnus.com>
[not found] ` <200002071626.RAA18391@landau.wins.uva.nl>
[not found] ` <bog9tj5y3.fsf@rtl.cygnus.com>
[not found] ` <20000207093417.A10546@lucon.org>
[not found] ` <200002071746.MAA22221@devserv.devel.redhat.com>
[not found] ` <20000207095901.A10677@lucon.org>
2000-04-01 0:00 ` Andrew Cagney
2000-04-01 0:00 ` Patrick J. LoPresti
2000-04-01 0:00 ` Mark Kettenis
[not found] <Pine.LNX.4.10.10002071633590.9778-100000@propylaea.anduin.com>
2000-04-01 0:00 ` Mark Kettenis
[not found] <200002082018.MAA12871@propylaea.anduin.com>
2000-04-01 0:00 ` Daniel Berlin
[not found] <389EC815.BC34F3E6@cygnus.com>
2000-04-01 0:00 ` Jason Molenda
[not found] <20000207174307.B12317@lucon.org>
2000-04-01 0:00 ` Daniel Berlin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=21267.950023252.0@NO-ID-FOUND.mhonarc.org \
--to=khendricks@admin.ivey.uwo.ca \
--cc=gdb@sourceware.cygnus.com \
--cc=patl@cag.lcs.mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox