From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29879 invoked by alias); 10 Feb 2014 14:34:59 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 29864 invoked by uid 89); 10 Feb 2014 14:34:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Mon, 10 Feb 2014 14:34:58 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id B1F6B11645A; Mon, 10 Feb 2014 09:34:56 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dSqIKmpubVTS; Mon, 10 Feb 2014 09:34:56 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 4CCB8116458; Mon, 10 Feb 2014 09:34:56 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 80023E075B; Mon, 10 Feb 2014 18:34:56 +0400 (RET) Date: Mon, 10 Feb 2014 14:34:00 -0000 From: Joel Brobecker To: Pedro Alves Cc: Eli Zaretskii , gdb-patches@sourceware.org Subject: Re: [Windows/RFA/commit] Deprecate windows-specific dll-symbols command and aliases Message-ID: <20140210143456.GC5485@adacore.com> References: <1391161706-340-1-git-send-email-brobecker@adacore.com> <834n4k75iu.fsf@gnu.org> <20140131113924.GB4101@adacore.com> <83zjmc5q2i.fsf@gnu.org> <52F14B9D.3000802@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52F14B9D.3000802@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2014-02/txt/msg00307.txt.bz2 > 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