Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Daniel Berlin <dberlin@dberlin.org>
To: mec.gnu@mindspring.com (Michael Elizabeth Chastain)
Cc: cagney@gnu.org, gdb@sources.redhat.com, cgf@alum.bu.edu
Subject: Re: bugzilla
Date: Thu, 08 Jul 2004 19:17:00 -0000	[thread overview]
Message-ID: <8149CF8E-D113-11D8-9149-000A95DA505C@dberlin.org> (raw)
In-Reply-To: <20040708180252.7C4534B104@berman.michael-chastain.com>


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).




  reply	other threads:[~2004-07-08 19:17 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-08 18:03 bugzilla Michael Elizabeth Chastain
2004-07-08 19:17 ` Daniel Berlin [this message]
  -- strict thread matches above, loose matches on Subject: below --
2009-10-14  0:56 Bugzilla Nick Roberts
2009-10-15  9:42 ` Bugzilla Doug Evans
2009-10-15 16:07   ` Bugzilla Tom Tromey
2009-10-17  1:05     ` Bugzilla Nick Roberts
2009-10-17  9:39       ` Bugzilla Tom Tromey
2009-10-18  1:03         ` Bugzilla Daniel Jacobowitz
2009-10-18  2:27           ` Bugzilla Nick Roberts
2009-10-18  2:46             ` Bugzilla Daniel Jacobowitz
2009-10-18 19:41               ` Bugzilla Joel Brobecker
2009-10-20  7:56                 ` Bugzilla Nick Roberts
2009-10-20 10:02                   ` Bugzilla Joel Brobecker
2007-03-21  8:00 Bugzilla Sascha Radike
2007-03-21 11:11 ` Bugzilla Daniel Jacobowitz
2007-03-21 11:29   ` Bugzilla Sascha Radike
2007-03-21 11:45     ` Bugzilla 'Daniel Jacobowitz'
2004-07-08 19:44 bugzilla Michael Elizabeth Chastain
2004-07-08 18:07 bugzilla Michael Elizabeth Chastain
2004-07-08 14:31 bugzilla Andrew Cagney
2004-07-08 14:52 ` bugzilla Daniel Berlin
2004-07-08 15:07   ` bugzilla Andrew Cagney
2004-07-08 15:11     ` bugzilla Daniel Jacobowitz
2004-07-08 15:17       ` bugzilla Daniel Berlin
2004-07-08 15:16     ` bugzilla Daniel Berlin
2004-07-08 14:59 ` bugzilla Dave Korn
2004-07-08 15:15   ` bugzilla Daniel Berlin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8149CF8E-D113-11D8-9149-000A95DA505C@dberlin.org \
    --to=dberlin@dberlin.org \
    --cc=cagney@gnu.org \
    --cc=cgf@alum.bu.edu \
    --cc=gdb@sources.redhat.com \
    --cc=mec.gnu@mindspring.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox