From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29320 invoked by alias); 8 Jul 2004 19:17:54 -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 29310 invoked from network); 8 Jul 2004 19:17:51 -0000 Received: from unknown (HELO dberlin.org) (69.3.5.6) by sourceware.org with SMTP; 8 Jul 2004 19:17:51 -0000 Received: from [192.168.1.7] (account dberlin HELO [192.168.1.7]) by dberlin.org (CommuniGate Pro SMTP 4.2b6) with ESMTP-TLS id 7063453; Thu, 08 Jul 2004 15:17:51 -0400 In-Reply-To: <20040708180252.7C4534B104@berman.michael-chastain.com> References: <20040708180252.7C4534B104@berman.michael-chastain.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8149CF8E-D113-11D8-9149-000A95DA505C@dberlin.org> Content-Transfer-Encoding: 7bit Cc: cagney@gnu.org, gdb@sources.redhat.com, cgf@alum.bu.edu From: Daniel Berlin Subject: Re: bugzilla Date: Thu, 08 Jul 2004 19:17:00 -0000 To: mec.gnu@mindspring.com (Michael Elizabeth Chastain) X-SW-Source: 2004-07/txt/msg00077.txt.bz2 On Jul 8, 2004, at 2:02 PM, Michael Elizabeth Chastain wrote: > I like bugzilla for gcc just great! > In particular, it's much easier to add attachments. > > Some requests: > > . add target/host/build fields similar to gcc bugzilla > > . add a field for the compiler used to build the test program. > i don't care what compiler is used to build gdb itself > (unless it's a build failure or a failure in selftest.exp). > i care a lot what compiler is used to write the program that > gdb is reading. occasionally i care about the binutils version > as well, but perhaps not enough to have a field for it. Adding new fields is a pain in the ass, and i try to do it when only *absolutely necessary*. This is because we don't use any of the generic custom fields patches to bugzilla, since none of them as they stand will ever make it into the bugzilla proper, and thus, using one would make merging to new bugzilla versions incredibly difficult (they always cause code conflicts). So if you guys want new fields, they need to be all decided before the merge, so i can add all the necessary display stuff, etc :). Not that i've never added a custom field later on, it's just that I try to avoid it whenever possible. At least until bugzilla itself gets a custom fields mechanism, which is probably eons away. I'm only one person, after all, and Bugzilla was just something i started doing to make life easier for gcc developers. It's not anywhere near my job description, and i actually hate perl. > . add a field for debug format. this can be drop down: > dwarf-2, stabs+, som, mdebug, ..., other. > . add instructions on running the 'script' command, > or running gdb inside emacs and capturing the session. > see a recent version of doc/gdb.info. > > . let us know where the online help is and how to edit it. > > . collapse 'priority' and 'severity' into one field, > or actually document what they mean in the online help. I can't do this if you use the sources bugzilla installation, since they use priority and severity. It would be possible to simply hide one of the fields when displaying gdb bugs, of course (IE you could just use severity, or just priority, for gdb bugs).