Using GCC Bugzilla for glibc

[Andreas Jaeger <aj at suse dot de>]

Hi glibc developers,

the offer below by the GCC Bugzilla masters is also valid for Glibc
(confirmed privately).

I have the following questions:

- Do we want to make that move?

- Does the GCC Bugzilla meet our needs (see below for the
  restrictions)?

- Who likes to be responsible on handling glibc bugs?  Note we don't
  need folks fixing bugs, but volunteers to verify reports, assign
  them, close them, ask for more details...

Andreas

--- Begin Message ---

• Subject: Topics

Topics:
   Merging binutils/gdb bug databases with the gcc bugzilla

--- End Message ---

--- Begin Message ---

• From: Wolfgang Bangerth <bangerth at ices dot utexas dot edu>
• To: gcc at gcc dot gnu dot org
• Cc: Bugzilla Masters <bugzilla-masters at dberlin dot org>
• Date: Wed, 17 Dec 2003 10:44:59 -0600 (CST)
• Subject: Merging binutils/gdb bug databases with the gcc bugzilla

So we discussed the matter somewhat on our bugmaster list, and the outcome
is: there aren't many strong feelings either way about having binutils or
gdb as a new product in the gcc database, but enthusiasm is generally low.  
It seems that the only significant benefit would be that only one database
would have to be maintained, but we didn't see much benefit for people
working with the databases.

There was, however, consensus that such a move is only acceptable if the
binutils and gdb people make sure that they have people that work on their
parts of the databases. These won't be the people working on gcc right
now, and we absolutely don't want to be blamed for some other project
piling up their bug reports unprocessed while we keep our house clean. It
may be that we help out with advice occasionally, but we don't want this
to be our responsibility. I think that it is our (gcc maintainers)  
collective experience that the bug database is only useful if it is
maintained continually, and other projects should make sure they do that
if they want to use the gcc bug database and web domain. (Can PRs be bulk
exported if things don't work out as hoped?)

Secondly, Dan Berlin, our bugzilla maintainer, requested that he's only 
willing to set up new products if he doesn't have to do additional work 
like adding fields, etc. Other projects would therefore have to make do 
with what we set up for gcc.

Thirdly: over time, I think we have come up with pretty reasonable 
procedures (like when to close a PR, what the individual fields mean, 
etc). But different products only profit from being in the same database 
if they keep to the same rules, so we should ask for a common set of rules 
for all products.

Regards (on behalf of the bug masters)
  W.

-------------------------------------------------------------------------
Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                               www: http://www.ices.utexas.edu/~bangerth/

--- End Message ---

Andreas
-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
  SuSE Linux AG, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

Attachment: pgp00000.pgp
Description: PGP signature