Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: "Daniel Berlin" <dan@cgsoftware.com>
To: khendricks@admin.ivey.uwo.ca, gdb@sourceware.cygnus.com
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: <950048577_PM_BeOS.dan@cgsoftware.com> (raw)
In-Reply-To: <200002082018.MAA12871@propylaea.anduin.com>

>
>What you are really saying here is that is better *not* to get 
something into 
>the tree that everyone can hack at and evenutully get to work.  Instead 
we never 
>incorporate and hope for some miracle that it gets fixed.?.?.?
>
What you are really saying is that it's better to put hacks and crap in 
the tree, and hope someone comes along and does it right, removing the 
hack, while making it even more a living hell for everyone else to 
understand.

>That logic is so completely flawed, that I am surprised you are 
defending it.
So is yours.
>
>We, the ppc people, have seen 4.16.97, 4.17.X, 4.18.X, and now 5.X come 
(or 
>coming) without support because of this "don't break anything 
mentality".  
>
That's not why at all.
You haven't seen support because nobody wants to do it right.

>Simply put isn't it just *better* to get in something and let the users 
help to 
>clean it up, make it work, improve it.  As a professor of TQM, waiting 
for 
>perfection is just not the way to achieve it.  Getting everyone 
involved is.

See, here is your fatal mistake.
You are making the assumption that users will clean it up, make it work, 
and improve it.
While this may be true in other projects, it's not really true in GDB's 
case.
In fact, it's only true in GCC's case because there are more people who 
understand the intricacies of compilers, and who are qualified to hack 
on the compiler, than their are who understand the intricacies of joe 
random platform's debugger interface.
When it comes to things like drivers and debuggers, users don't really 
help much, unless the architecture is so amazingly easy to understand 
it's absurd. Which it isn't. Having ported sound drivers and whatnot to 
BeOS, and talked with quite a few authors of sound drivers on linux, the 
general consensus is that nobody submits patches. Their is the 
occasional person who really enjoys hacking on undocumented hardware, or 
poorly documented debugger interfaces, and who submits patches, but they 
are very very rare.
So what about the non-platform specific parts of GDB that are 
understandable, and hackable?
well, for the most part, they work great, and people are happy with 
them, and thus don't submit patches.
But just ot prove my point, when is the last time you saw a user submit 
a patch for dwarf2 support, or C++ overload resolution (discounting me), 
or support for a new platform?
It just doesn't happen all that often.

Accepting hackish patches won't change this. It's not going to mean 
random people are going to start submitting more patches. It'll just 
mean one more hack in the tree (Although the patch is starting to shape 
up), and one more hack for the occasional few who want to try to 
comprehend how it works, to sort through.

--Dan



-----------------------------------
This message was sent with the demo version of Postmaster, a BeOS mail client.
For more information, please visit http://kennyc.com/postmaster


       reply	other threads:[~2000-04-01  0:00 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200002082018.MAA12871@propylaea.anduin.com>
2000-04-01  0:00 ` Daniel Berlin [this message]
     [not found] <20000207174307.B12317@lucon.org>
2000-04-01  0:00 ` Daniel Berlin
     [not found] <389EC815.BC34F3E6@cygnus.com>
2000-04-01  0:00 ` Jason Molenda
     [not found] <Pine.LNX.4.10.10002071633590.9778-100000@propylaea.anduin.com>
2000-04-01  0:00 ` Mark Kettenis
     [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
2000-04-01  0:00 Kevin_Hendricks

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=950048577_PM_BeOS.dan@cgsoftware.com \
    --to=dan@cgsoftware.com \
    --cc=gdb@sourceware.cygnus.com \
    --cc=khendricks@admin.ivey.uwo.ca \
    /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