From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31327 invoked by alias); 1 Aug 2008 16:14:24 -0000 Received: (qmail 31316 invoked by uid 22791); 1 Aug 2008 16:14:23 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 01 Aug 2008 16:14:02 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KOxGK-00060T-Pb for gdb@sources.redhat.com; Fri, 01 Aug 2008 16:13:52 +0000 Received: from 78.158.192.230 ([78.158.192.230]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 01 Aug 2008 16:13:52 +0000 Received: from vladimir by 78.158.192.230 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 01 Aug 2008 16:13:52 +0000 To: gdb@sources.redhat.com From: Vladimir Prus Subject: Re: Move GDB to C++ ? Date: Fri, 01 Aug 2008 16:14:00 -0000 Message-ID: References: <487658F7.1090508@earthlink.net> <20080801131312.GA14712@caradoc.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.10.9 X-IsSubscribed: yes 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-08/txt/msg00022.txt.bz2 Eli Zaretskii wrote: >> Date: Fri, 1 Aug 2008 09:13:12 -0400 >> From: Daniel Jacobowitz >> Cc: Vladimir Prus , gdb@sources.redhat.com >> >> On Thu, Jul 31, 2008 at 09:42:28PM +0300, Eli Zaretskii wrote: >> > > From: Vladimir Prus >> > > Date: Thu, 31 Jul 2008 10:10:37 +0400 >> > > >> > > I think this discussion went a bit wrong way -- trying to convince folks that >> > > *investing effort* in converting to C++ is justified. However, I don't think >> > > the proposal is about making folks not interested in C++ doing any work -- the >> > > proposal is about allowing folks who do some specific work, and want to make >> > > use of additional features C++ provides, to use those features, while not imposing >> > > significant problems on the rest of contributors. >> > >> > Your being busy refactoring does impose a significant problem on me. >> > We are members of the same team, so how you use your time while on the >> > team is important to me. >> >> Could you please expand on this idea? > > The idea is that a maintainer cannot behave with the code as he > pleases, claiming that it's his time and therefore his, and only his, > business. > > The idea is also that GDB is a collective effort, so arguments saying > "I will do this because I like it, and you shouldn't care" are not > something I'm willing to accept. I don't think anybody ever said the phrase you've quoted. You, as a global maintainer can care about any patch posted to gdb-patches as you see fit. But I think that objections to any decision in any patch should focus on specific technical issues, or lack thereof, in the end result. For example, every time I do any nontrivial work, I look at existing code, and try to see if it can be made more hackable. As result, I might post a patch that takes a 400-line function and extracts a couple of fragments into separate functions. You might respond asking why I think those are the right fragments to extract, whether the names of new functions makes sense, and so on. But on the other hand saying "don't waste your time on refactoring, just hack you change in" would seem wrong -- if it's me doing the work, then I know the most efficient way for me, so as long as each individual patch makes thing better and the end goal is achieved, things are OK. Why should not all technical decisions viewed this way? If I post a patch that makes use of a C++ feature, then it's reasonable to object if this feature makes the code more obscure or less maintainable, or increases GDB footprint. But if none of those issues are present, why prevent me from using the feature? Or why demand that I prove that use of this feature makes *me* more productive and whether just hacking the immediate change in would be faster? The *only* global decision here, is whether to use C++ compiler when building GDB and I think that decision should be used on purely practical concerns. Say, if 100 people believe use of C++ features will make them more productive, 100 people who would not use C++ features anyway, and it turns out that there's exactly one platform that will not be able to compile GDB if it switches to C++, and that platform is EOLed in 1980, then I think the decision is clear. And it that case, the first 100 people need to convince the other 100 people that they should use C++ features -- they are happy not to. >> GDB is a GNU project, driven by volunteers and sponsored contributors. >> And the sponsored contributors are volunteers from the perspective of >> anyone outside the sponsoring organization. I don't understand the >> objection to other people choosing to invest effort on something, even >> if you think it's unimportant. Volunteer projects go where their >> volunteers want to take them! > > We are not talking about just any change here. We are talking about a > change that will affect everyone. Taking a volunteer project in such > directions without consensus isn't right, IMO. Vladimir's message in > effect tried to side-step the lack of consensus, which is not how I > thought GDB development should advance. It's not exactly true; I there are various consensuses that are possible. It seems to me like we were trying to reach concensus on the following statement: "Everybody should stop doing anything, quit their jobs, go to desert, and hack on converting GDB to C++ without rest" Naturally, this is not a defensible statement, and I think the statement to discuss is: "There's quite a number of people who say they will be more productive using C++ and C++ will bring little inconvenience to the rest, so allowing using C++ is a net gain" The folks who say they are more productive with C++ are not teenagers, or even students, so I think it reasonable to trust their opinion about their own productivity. Do you agree? Then, the above statement can be false only if the inconvenience is as bit as to make the result a net loss. So far, only Mark has provided concrete concerns -- namely that requiring C++ might make some targets unviable. Do you know of specific inconveniences that will affect you, personally? - Volodya