Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Michael Elizabeth Chastain <mec@shout.net>
To: drow@mvista.com, gdb@sources.redhat.com
Subject: Re: [rfc] xfailed tests in gdb.c++/classes.exp
Date: Fri, 28 Feb 2003 05:01:00 -0000	[thread overview]
Message-ID: <200302280501.h1S51oS26231@duracef.shout.net> (raw)

> Sure.  But I suspect 2) represents an actual bug.  Fixing this is about
> three lines in c-typeprint.c.  Should we or shouldn't we?

A little late night rambling ...

It depends on your role.

In the QA role I've got kind of a black-boxy view.  If the test script
mimics what a user would type, and if I think that most users would be
happy, then I'm happy.

In the developer role, any loose edge might be a symptom of a bug.  I
remember when one little test in selftest.exp did not pass and I traced
it down to memory corruption inside gdb.  And we all know that a stitch
in time saves nine.  If you're looking at results that don't match what
you, as a developer, believe the code should do, that is noteworthy,
even if Joe User has no issue with it.

Also, gdb has thousands more problems than we can fix.  We have to do
brutal triage on our TODO lists, every day.  And I am personally bad at
prioritizing.  In fact one of my motives for working on gdb is to
practice better prioritizing in an environment that lets me set my own
goals.

Michael C


             reply	other threads:[~2003-02-28  5:01 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-28  5:01 Michael Elizabeth Chastain [this message]
2003-02-28 15:15 ` Daniel Jacobowitz
2003-02-28 17:58   ` David Carlton
  -- strict thread matches above, loose matches on Subject: below --
2003-02-28  3:51 Michael Elizabeth Chastain
2003-02-28  3:59 ` Daniel Jacobowitz
2003-02-28 13:40   ` Paul Koning
2003-02-28 20:58 ` Jason Molenda
2003-01-03 23:27 Michael Elizabeth Chastain
2003-01-03 22:53 David Carlton
2003-02-28  1:30 ` Daniel Jacobowitz

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=200302280501.h1S51oS26231@duracef.shout.net \
    --to=mec@shout.net \
    --cc=drow@mvista.com \
    --cc=gdb@sources.redhat.com \
    /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