From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9595 invoked by alias); 7 Oct 2004 18:01:25 -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 9563 invoked from network); 7 Oct 2004 18:01:22 -0000 Received: from unknown (HELO takamaka.act-europe.fr) (142.179.108.108) by sourceware.org with SMTP; 7 Oct 2004 18:01:22 -0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 672D447D98; Thu, 7 Oct 2004 11:01:21 -0700 (PDT) Date: Thu, 07 Oct 2004 19:18:00 -0000 From: Joel Brobecker To: Dave Korn Cc: 'Andrew Cagney' , 'Eli Zaretskii' , gdb@sources.redhat.com Subject: Re: Discussion: Formalizing the deprecation process in GDB Message-ID: <20041007180121.GL1282@gnat.com> References: <416562C9.90801@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-SW-Source: 2004-10/txt/msg00228.txt.bz2 > > A running joke between several of the GDB developers at the last GCC > > summit was that we should present a 1hr paper titled "porting > > GDB to a > > new architecture". Only instead of presenting slides, we'd > > just write the code. > > I find it hard to believe that's possible for anyone who comes to > the code from fresh. You have spent years working with gdb and have > the advantage of knowing your way round the code, and what the > replacements for each deprecated thing are; anyone else has to do > lots of research. If there's going to be a formalization of the > deprecation process, my 'feature request' would be that there be one > single central place where all deprecated features are listed > together with brief pointers to the new functionality that has taken > their place. Yes, it would be hard for a newbie to port GDB to a different architecture in an hour. Or I'd be very impressed :-). 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. 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. It's simpler to put that information directly in the code, and most of the time, the information is actually already there. I have to say that GDB's learning curve is not that steep, compared to other projects I have worked on. You don't necessarily need to grab the whole picture before you can actually start working effectively on it. I have been contributing to GDB for several years now, and I honestly still think that I don't have a complete global view of GDB yet. Some areas I know very well, I have a rough idea of the major components, how they interact, but some important areas are still unexplored territory. If I had this global view, I think I could be promoted as global maintainer :-). -- Joel