From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8478 invoked by alias); 28 Sep 2003 22:45:46 -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 8471 invoked from network); 28 Sep 2003 22:45:46 -0000 Received: from unknown (HELO concert.shout.net) (204.253.184.25) by sources.redhat.com with SMTP; 28 Sep 2003 22:45:46 -0000 Received: from duracef.shout.net (duracef.shout.net [204.253.184.12]) by concert.shout.net (8.12.10/8.12.10) with ESMTP id h8SMjh0U028031; Sun, 28 Sep 2003 17:45:43 -0500 Received: from duracef.shout.net (localhost [127.0.0.1]) by duracef.shout.net (8.12.10/8.12.9) with ESMTP id h8SMjhVd026917; Sun, 28 Sep 2003 17:45:43 -0500 Received: (from mec@localhost) by duracef.shout.net (8.12.10/8.12.9/Submit) id h8SMjhoO026916; Sun, 28 Sep 2003 18:45:43 -0400 Date: Sun, 28 Sep 2003 22:50:00 -0000 From: Michael Elizabeth Chastain Message-Id: <200309282245.h8SMjhoO026916@duracef.shout.net> To: eliz@elta.co.il Subject: Re: Tracepoint support in Cygnus GDB ? Cc: gdb@sources.redhat.com X-SW-Source: 2003-09/txt/msg00355.txt.bz2 Eli Zaretskii writes: eli> In other words, I'd be happier if a larger portion of GDB maintenance eli> resources were to go into more platform-independent features. I want to address this issue. GDB development is not like a project chart where there are resources and then the manager assigns the resources. GDB development is more like an ecosystem, where a bunch of animals come into the environment and interact with each other. You can control directly the maintainer resources that you contribute. If someone is listed as a maintainer you can ask them to perform the functions of their maintainership (review your patches). You can nag people, or inspire people, to do things that you think are important. But we don't take orders from a centralized leader. eli> Are you saying that there's no way we could set up practical goals for eli> GDB development? I'd be surprised if you actually meant that, but eli> that's how it sounds. In my humble view, that's right: there is no way "we" can set up practical goals for GDB development. I can set up goals for my contributions, and I do. For instance, my goals include: run the test suite regularly publish exhaustive analyses on the differences complain about gdb regressions from week to week file a PR for each gdb regression from the previous public release make the responsible developers aware of those PR's file a PR for each gcc regression in gcc debug info # I think I'm actually the primary guy who tests gcc debug info! respond to user questions on gdb@ and bug-gdb@ respond to user bug reports in gnats maintain testsuite/gdb.cp contribute to the overall testsuite write doco that i think the users need I self-generated these goals. I'm open to input on them, but basically, you would have a hard time convincing me to change my overall philosophy from my vision (QA) to your vision (user-level features). I suspect the same is true for most gdb contributors. Michael C