Re: [patch] gdb.c++/local.exp: add pr numbers

[Daniel Berlin <dberlin at dberlin dot org>]

On Sun, 2002-04-14 at 02:40, Michael Elizabeth Chastain wrote:
> 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.
Ah, you are confused because gnats has different databases for different
products, while bugzilla supports multiple products in a single
database.
To be clear:
1. Bugzilla supports multiple products by default, in a single database.
(Each product can itself, have multiple components, as well)
2. Bug ids are unique within a given bugzilla database.

Thus, gdb bug numbers and gcc bug numbers will never conflict, once they
are in the same bugzilla system.

However, this *is* actually going to be annoying in the initial import,
since it means that if they share the same bugzilla system (which only
makes sense), i'll have to remap gdb's bug numbers to a new range (IE
add 10000 to them. There are almost exactly 7000 gcc bug reports, and
not going to be 3000 more before we switch)

Once the initial import is done, there will be no further problems,
since,as I said, bug numbers are unique to a given bugzilla database,
not to a given product in that database.

Think of it from the SQL database point of view.
(I'm simplifying, since comments/attachments are in a seperate table).
All bugs, for a given bugzilla installation are stored in a table, with
a primary key of the bug id.
The product is just another field on the bug.

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