This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |