This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project.


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

Re: Preparing for the GDB 5.0 / GDB 2000 / GDB2k release


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


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