Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: mec.gnu@mindspring.com (Michael Elizabeth Chastain)
To: cagney@gnu.org, mec.gnu@mindspring.com
Cc: gdb-patches@sources.redhat.com
Subject: Re: [patch/rfc] Add meaningful section titles to PROBLEMS
Date: Fri, 19 Mar 2004 17:45:00 -0000	[thread overview]
Message-ID: <20040319174517.856F74B104@berman.michael-chastain.com> (raw)

mec> I'm willing to abide by whatever Eli, the maintainer, decides.
ac> I don't know who the maintainer is, however doco and releng should be 
ac> "on the same page".

Well, then I think you need to decide who the maintainer of PROBLEMS
is and document that in the MAINTAINERS file.  There are no specific
entries for "releng" so I presumed they fell under documentation.

ac> As I stated in my cover note, gdb/1560 for instance is a regression 
ac> since GDB _5.0_.

Okay, then a user of gdb 6.0 is not going to suffer from additional
hurt from gdb/1560 if they upgrade to gdb 6.1.  And you are right, it's
not a regression from 6.0.

ac> Trying to list regressions is of little value.

We have different opinions on this.

When I upgrade a software package, I find the list of regressions from
my current version to be of *great* value.  For each new problem, I have
to ascertain whether it affects my system.  If it affects my system, I
have to figure out how to work around the problem.  If the problems are
too severe, then I know that I am better off not upgrading.

ac> Giving this file meaningful titles (so users don't have to wade through
ac> irrelevances such as gdb/1512) is a first step.

gdb/1512 is a bug in gdb.  Naturally, we can describe it so that most
people will realize that it won't bother them and can just read through
to the next bug.

If you claim that gdb/1512 is irrelevant to every user (and I'm almost
of that opinion myself), and you can persuade other maintainers of that
position, then we can stop testing for it and just PASS those tests.
But right now we consider that behavior of gdb to be a bug that needs
fixing.

Michael C


             reply	other threads:[~2004-03-19 17:45 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-19 17:45 Michael Elizabeth Chastain [this message]
2004-03-20 15:26 ` Eli Zaretskii
  -- strict thread matches above, loose matches on Subject: below --
2004-03-19 16:50 Michael Elizabeth Chastain
2004-03-19 17:22 ` Andrew Cagney
2004-03-19 16:16 Andrew Cagney
2004-03-19 17:13 ` David Carlton
2004-03-19 17:33   ` Andrew Cagney
2004-03-19 17:43     ` David Carlton
2004-03-19 19:59       ` Andrew Cagney
2004-03-20 15:22         ` Eli Zaretskii
2004-03-20 15:29       ` Eli Zaretskii
2004-03-20 15:34 ` Eli Zaretskii
2004-03-25 21:07   ` Andrew Cagney

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=20040319174517.856F74B104@berman.michael-chastain.com \
    --to=mec.gnu@mindspring.com \
    --cc=cagney@gnu.org \
    --cc=gdb-patches@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