From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16648 invoked by alias); 7 Oct 2004 18:08:20 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 16565 invoked from network); 7 Oct 2004 18:08:19 -0000 Received: from unknown (HELO NUTMEG.CAM.ARTIMI.COM) (217.40.111.177) by sourceware.org with SMTP; 7 Oct 2004 18:08:19 -0000 Received: from mace ([192.168.1.25]) by NUTMEG.CAM.ARTIMI.COM with Microsoft SMTPSVC(6.0.3790.0); Thu, 7 Oct 2004 19:07:57 +0100 From: "Dave Korn" To: "'Joel Brobecker'" Cc: "'Andrew Cagney'" , "'Eli Zaretskii'" , Subject: RE: Discussion: Formalizing the deprecation process in GDB Date: Thu, 07 Oct 2004 19:28:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: <20041007180121.GL1282@gnat.com> Message-ID: X-OriginalArrivalTime: 07 Oct 2004 18:07:57.0236 (UTC) FILETIME=[92DFBF40:01C4AC98] X-SW-Source: 2004-10/txt/msg00229.txt.bz2 > -----Original Message----- > From: Joel Brobecker > Sent: 07 October 2004 19:01 > Anyway, like in any project, there is a learning curve, and that > curve can be reduced to a certain degree by good documentation. > However, you have to balance the amount of document your write > and *maintain* with the amount of work this saves for some potential > contributor. Yeh, of course, and being a relative newbie, it's hard for me to tell how much (if any) of the difficulty I face is down to not having the right balance (or just not enough docs), and how much of it is just inevitable learning curve stuff. > I think that maintaining the list of deprecated features > in a separate document is going to be a large amount of work. > GDB is changing so fast. Erm... things that get deprecated don't often get un-deprecated, do they? Wouldn't it largely be a matter of just adding a couple of lines each time something gets deprecated, just enough to say "All this stuff is now replaced by the new XXXX mechanism; use XXXXX_do_whatever in place of deprecated_OLDXXXXXX_do_somethingelse, or see gdb-XXXXX.h for more information." Or words to that effect. Shouldn't it be possible for the old entries in that document to then remain more or less static? I'm envisaging something that's a bit like a specialized changelog, but rather than file-by-file and function-by-function descriptions of changes, which are a bit low-level, it would have a list of deprecated functionalities and their replacements. cheers, DaveK -- Can't think of a witty .sigline today....