From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1438 invoked by alias); 19 Feb 2003 14:50:09 -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 1402 invoked from network); 19 Feb 2003 14:50:06 -0000 Received: from unknown (HELO localhost.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 19 Feb 2003 14:50:06 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 2584D2D37; Wed, 19 Feb 2003 09:54:51 -0500 (EST) Message-ID: <3E539ABA.4050203@redhat.com> Date: Wed, 19 Feb 2003 14:50:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD i386; en-US; rv:1.0.2) Gecko/20030217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz , Jim Blandy Cc: gdb@sources.redhat.com Subject: Re: [maint] The GDB maintenance process References: <20030217180709.GA19866@nevyn.them.org> <20030218042847.50F2E3CE5@localhost.redhat.com> <20030217180709.GA19866@nevyn.them.org> <20030218023553.2BBB73D02@localhost.redhat.com> <20030217180709.GA19866@nevyn.them.org> <15953.20132.193102.752916@localhost.redhat.com> <20030219014904.GA11446@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-02/txt/msg00342.txt.bz2 > Sure. But my portrayal isn't entirely inaccurate, either. One example > - inter-compilation-unit references in DWARF-2. It's been posted at > least twice, by different contributors. When asked for changes, > they've come back with changes. It's still not supported, over a year > later. Yes, I think it is fair to say that we've recently dropped baton on that one :-( JimB, what's the current status? Anyway a mid-mortem is in order. GDB has a serious problem with _old_ forks. cf: - hp fork - apple fork - act's fork - caldera's fork You'll note that, in each of these cases, they really are forks(1). The relevent developers created their own repository and then went off into the wilderness only to mysteriously appear later with a jumbo patch. I believe that decision for forking was largly driven by the desire to, due to short term commercial pressure, avoid doing the right thing. Not unreasonably, the GDB developers asked that such jumbo patches be broken down into something more managable, more up-to-date, and (too often) `lint' free(2). Also, not unreasonably, the GDB developers asked/questioned architectural decisions made on those branches. Less realistic, perhaps, is an over expectation of how much a contributor can reasonably be asked. Even ignoring those `comercial pressures', many contributors figure `take it or leave it'. Maintainers need to be willing to not only spend time adding glamerous new features, but also when an important patch appears, pick it up and run with it(3). One thing GCC(4) and GDB are now is encouraging exprementation on branches development to always occure on branches cut from the the relevant repository. For GDB we've had both success stories but also disasters. With that in mind, and looking at the GCC / GDB success stories, I'd suggest the following guidelines: - branches shall post all commits They don't need approval but can be commented on. - branches shall to be focused The interps branch started out too large with too many changes - look at the size of the final commit compared to that branch at its peak. Much time was lost because the branch started with too much lint :-( - branches shall track mainline. This keeps the level of divergence under control. It also keeps the pressure on developers to push cleanups and other stuff into the mainline. Andrew -- (1) I was discussing this with a GCC developer and they pointed out, for the reasons I note, that these are not branches. (2) As in the stuff you find on your clothing (not the program). Forks and branches, like navel's, are shockers for breeding lint - entropy that serves no useful purpose. (4) Yes, as I mentioned, I discuss this with GCC developers to see what lessons can be learnt. (3) Note that if I pick up a really old patch, I'll often review, tweak and commit it. I figure that if a patch is more than a month old, it isn't realistic to be asking a contributor to make minor changes.