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: Wed, 12 Feb 2014 17:17:00 -0000 [thread overview]
Message-ID: <20140212171738.GR5485@adacore.com> (raw)
In-Reply-To: <52FB88CB.6000706@redhat.com>
Hi Pedro,
> So it seems like we have 3 possible policies:
>
> #1 - Leave the manual unchanged when we deprecate commands. Delete
> the documentation at the same time the command is actually
> deleted.
>
> #2 - Always excise documentation for deprecated commands at the same
> time we do the deprecation.
>
> #3 - Mark the commands deprecated in the manual at the same time
> we mark them deprecated in the code. Delete the documentation
> at the same time the command is actually deleted.
>
> In my view, #1 is just a bad policy. Having documentation
> for deprecated commands behind _without_ a "deprecated,
> use foo instead" note in them might lead users to find
> the old command and start using them while newer better
> alternatives exist. I think everyone will agree to that.
>
> And in my view, #3 is a superior policy than #2. But
> I'll accept #2, if that's what the group ends up preferring.
>
> Whatever we end up deciding, I think we should document
> the outcome as guideline somewhere in the internals
> manual, and if we go with #2, then we it'd be good
> to make a pass over the manual and remove all the
> existing documentation for currently deprecated
> commands.
I understand your reasoning, and can agree with you in the sense
that someone already using the deprecated command might want to
look some detail up in the GDB manual and not find it.
But I do not have a strong opininon on this, and whatever we end up
deciding is fine by me. Let's just decide now :). I will go with #3,
or else #2.
--
Joel
next prev parent reply other threads:[~2014-02-12 17:17 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
2014-02-12 14:44 ` Pedro Alves
2014-02-12 17:17 ` Joel Brobecker [this message]
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=20140212171738.GR5485@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