From: Joel Brobecker <brobecker@adacore.com>
To: Pedro Alves <palves@redhat.com>
Cc: Eli Zaretskii <eliz@gnu.org>, gdb-patches@sourceware.org
Subject: Re: [Windows/RFA/commit] Deprecate windows-specific dll-symbols command and aliases
Date: Mon, 10 Feb 2014 14:34:00 -0000 [thread overview]
Message-ID: <20140210143456.GC5485@adacore.com> (raw)
In-Reply-To: <52F14B9D.3000802@redhat.com>
> I'm not sure I agree with that policy. I mean, we shouldn't advertise
> them, yes, and I think we do hide deprecated commands in the CLI
> at places, IIRC, but as long as they exist, I think they should
> be documented. IMO, it'd be nicer to users who are currently using
> such commands, and find out they're deprecated (because GDB warns) if
> they go to the manual and find both the replacement they should be
> using (and how), and the docu for the old command, so they can easily
> map arguments, etc. IOW, IMO, we should instead add a "This command is
> deprecated; a better alternative is blah blah" note. When I grep
> for deprecate_cmd, and then look for the documentation of the
> corresponding deprecated commands, I do find it.
> E.g., "record restore", "disable tracepoint", "set remotebreak", etc.
My 2 cents: I think it's fine to either remove the documentation, or
else leave it as is. Adding more info as you suggest is indeed making
the documentation better, but only for a short period of time. During
that period of time, if people happen to read about the deprecated
command in the manual, and then actually use that function, they'll
immediately get a warning, the warning will tell them which command to
use in its place. On the other hand, if we excise the commands'
documentation and they are searching the users manual, the only
command they can find are the non-deprecated ones.
In that respect, I now tend to agree with Eli. But it's not a strong
opinion.
--
Joel
next prev parent reply other threads:[~2014-02-10 14:34 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-31 9:48 Joel Brobecker
2014-01-31 11:30 ` Eli Zaretskii
2014-01-31 11:39 ` Joel Brobecker
2014-01-31 11:49 ` Eli Zaretskii
2014-01-31 12:22 ` Joel Brobecker
2014-01-31 14:33 ` Eli Zaretskii
2014-02-04 20:20 ` Pedro Alves
2014-02-10 14:34 ` Joel Brobecker [this message]
2014-02-12 14:44 ` Pedro Alves
2014-02-12 17:17 ` Joel Brobecker
2014-02-13 12:01 ` Joel Brobecker
2014-02-13 16:02 ` Eli Zaretskii
2014-02-13 16:43 ` Joel Brobecker
2014-02-13 17:03 ` Eli Zaretskii
2014-02-13 17:24 ` Pedro Alves
2014-02-13 17:40 ` Eli Zaretskii
2014-02-19 9:43 ` Joel Brobecker
2014-02-19 16:44 ` Eli Zaretskii
2014-02-20 8:34 ` Joel Brobecker
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=20140210143456.GC5485@adacore.com \
--to=brobecker@adacore.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=palves@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