From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4386 invoked by alias); 14 Jul 2008 17:53:08 -0000 Received: (qmail 4378 invoked by uid 22791); 14 Jul 2008 17:53:08 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 14 Jul 2008 17:52:43 +0000 Received: (qmail 23701 invoked from network); 14 Jul 2008 17:52:42 -0000 Received: from unknown (HELO localhost) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 14 Jul 2008 17:52:42 -0000 From: Vladimir Prus To: Robert Dewar Subject: Re: Move GDB to C++ ? Date: Mon, 14 Jul 2008 17:53:00 -0000 User-Agent: KMail/1.9.9 Cc: gdb@sources.redhat.com References: <487658F7.1090508@earthlink.net> <200807142023.04952.vladimir@codesourcery.com> <487B8139.9030803@adacore.com> In-Reply-To: <487B8139.9030803@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807142152.29924.vladimir@codesourcery.com> Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-07/txt/msg00169.txt.bz2 On Monday 14 July 2008 20:39:21 Robert Dewar wrote: > Vladimir Prus wrote: > > > I think you're falling into a trap common for planning large transitions. > > It seems reasonable to prepare of list of points, and compare alternatives > > on each point. However, I never saw this work, > > I have seen it work many times, and managed several transitions of > this type ... Probably, you've managed that in a commercial company? Because in open-source, you rarely have a single manager who can be used to resolve issues on which no concensus can be reached in reasonable time. > > Most transitions I saw involved: > > 1. A few folks pushing for specific solution that improves on the current > > status quo. > > 2. Other folks expressing opinions like "we absolutely need XXX" > > Sounds like they were badly mismanaged You are free to feel this way. But to give a concrete example, switch to SVN, for many projects such as GCC or C++ Boost, definitely improved things and therefore were much better thing than endlessly discussion which version control is best. > > So, here, what are your most important concerns? Do you see those concerns can > > be mitigated, or not? > > > The problem is the book named "The C++ Programming Language" went through at > > least 3 revisions, presumably with extra help of professional editors. Do we want > > to beat that? And why newcomers who already read this book should read the > > documentation for our non-standard mechanisms. > > Well I don't know the code well enough, but what exactly do you mean > by non-standard here---not conforming to the C standard??? I mean a high-level design patterns and constructs that closely correspond to existing constructs of C++, but yet implemented in a home-grown way, and unknown to either C++ programmers or C programmers outside GDB. > The GDB code > I *have* looked at all seems like fairly standard C to me! Tom has posted a list of such things in GDB, did you look at that list? - Volodya