From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21947 invoked by alias); 14 Apr 2002 06:41:01 -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 21932 invoked from network); 14 Apr 2002 06:40:57 -0000 Received: from unknown (HELO duracef.shout.net) (204.253.184.12) by sources.redhat.com with SMTP; 14 Apr 2002 06:40:57 -0000 Received: (from mec@localhost) by duracef.shout.net (8.11.6/8.11.6) id g3E6etF27586; Sun, 14 Apr 2002 01:40:55 -0500 Date: Sat, 13 Apr 2002 23:41:00 -0000 From: Michael Elizabeth Chastain Message-Id: <200204140640.g3E6etF27586@duracef.shout.net> To: dberlin@dberlin.org Subject: Re: [patch] gdb.c++/local.exp: add pr numbers Cc: ac131313@cygnus.com, gdb-patches@sources.redhat.com X-SW-Source: 2002-04/txt/msg00496.txt.bz2 Daniel Berlin writes: I am going to hold off on my bug-referencing patches to gdb.c++/*.exp while we have some discussion. > Bugzilla bug ids for gnats bugs will be the same as they were for gnats. Okay. > Um, if you simply write something fitting the regex bug(\s|%\#)*(\d+) , > bugzilla will make it link to the bug in question. That sounds mostly good to me. (Right now I am really glad that I've learned enough Perl to read those Perl regex's). However, it looks like the "gdb" part is implicit, such as: bug %#277 I want to mark all the gdb bugs (KFAILs) with gdb bug numbers, so that would work. I also want to mark all the environment bugs (XFAILs) with bug numbers for their corresponding systems. How can I cite a gcc bug number in a gdb XFAIL? Similarly, if someone outside gdb wants to refer to a gdb bug, then "bug %#277" is not quite enough context, because it doesn't specify which bugzilla database it's talking about. I'd like it better if there were a form with the bugzilla database name in the string. > I'm not going to modify the bugzilla source (to recognize any other > citation forms, as this highlighting is done in a routine used all over > the place (and thus, it's harder to verify a given regex does what you > expect in all cases), and I am specifically trying to avoid making any > changes to the perl source that can be avoided (the templates are > expected to be changed). Well, I think any coherent system is better than what we have now, which is no information. If I can mark all the KFAILs, and let the XFAILs twist in the wind, I can live with that. Michael C