From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13056 invoked by alias); 24 Apr 2002 15:53:19 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 12939 invoked from network); 24 Apr 2002 15:53:12 -0000 Received: from unknown (HELO mail-out2.apple.com) (17.254.0.51) by sources.redhat.com with SMTP; 24 Apr 2002 15:53:12 -0000 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id g3OFrBs14231 for ; Wed, 24 Apr 2002 08:53:11 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 24 Apr 2002 08:53:10 -0700 Received: from apple.com (vpn-gh-556.apple.com [17.254.138.43]) by scv3.apple.com (8.11.3/8.11.3) with ESMTP id g3OFrAv05124; Wed, 24 Apr 2002 08:53:10 -0700 (PDT) Message-ID: <3CC6D4E2.E5858735@apple.com> Date: Wed, 24 Apr 2002 08:53:00 -0000 From: Stan Shebs X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: drow@mvista.com, gdb-patches@sources.redhat.com Subject: Re: which patches to review References: <20020422.224035.88562706.davem@redhat.com> <15557.29643.263642.453067@localhost.redhat.com> <20020423105459.A8292@nevyn.them.org> <20020423.220943.39181580.davem@redhat.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-SW-Source: 2002-04/txt/msg00944.txt.bz2 "David S. Miller" wrote: > > Much of the commentary has been "the maintainers don't have the time", > and my main point is that this is a self-fulfilling prophecy. There > are never going to be new up and coming GDB contributors, ie. the new > manpower needed, if the status quo continues like this. The system literally can't work if maintainers don't have the time to review patches. Maintainers either need to devote more time to reviewing, or spend less time on each patch, or step back in favor of someone who can do the job. > Working on GCC/Binutils vs. GDB is like night and day, and I do not > believe this has %100 to do with manpower issues, it's partly because > of the approach taken by the maintainers to some extent. This is a > very large barrier to entry to get real work done on GDB, whereas for > GCC/Binutils there really isn't. One of the differences I notice with GCC is that there is less agonizing over every detail of every patch. When I put the basic Darwin support into GCC, the files actually carried along some crufty dead code inherited from old NeXT stuff, but since it only affected Darwin, nobody worried about it (since then most of it has been whacked). There have been other patches that were brave attempts, and looked good at first sight, but that didn't last a week and had to be reverted. No biggie, that's just a normal part of the development process. Another thing I notice with GCC is that while there is a wish list for future development directions, patches are usually not held hostage to that list. It's OK for instance to wish that a contributor would multi-arch an old macro instead of submitting yet another use of it, but if the contributor doesn't want to do that, take the patch anyway and worry about multi-arching later. Stan