bugzilla for glibc: let's get moving!

[Andreas Jaeger]

Roland McGrath <roland@redhat.com> writes:

> If you are listed in the CC: header, please reply to this message (see below)!
>
> I think we are ready to start using bugzilla for glibc.  So let's get this
> show on the road!  There are plenty of things still to figure out about how
> we use the system.  But there's no better way to hash those out than to get
> started with trying to use it.
>
> If you are reading this message and you do not already have an account on
> http://sources.redhat.com/bugzilla/ then please go sign up right now!
> Choose for your bugzilla account the email address that you would like
> email about glibc bugs sent to.
>
> Take a look at http://www.gnu.org/software/libc/bugs.html and tell me if
> you have any comments or suggestions for that page.  My intent is to make
> that URL the single canonical reference for glibc bug reporting; it says a
> few things and has links to bugzilla.  All the various places that embed an
> email address or instructions to use glibcbug will instead give this one
> URL.  If the details of the bug system change again in the future, that
> page's links can be updated to point to a new system.  Once I finish
> getting web pages and email aliases set up, I will commit some changes en
> masse to make everything in the source tree refer to the new (and hopefully
> permanent this time) places.

Good idea.

I suggest to look at the GCC bug page and copy stuff from there.  We
should explictly stress that we need self-contained testcases and
cannot debug any complex programs.

> There wasn't much response to my previous posting about components we'll
> use in bugzilla to categorize bug reports.  I am again proposing a list of
> components, with initial owners.  The person listed as owner will be the
> person who gets automatically assigned bug reports filed under this
> category.  That doesn't mean you have to fix it, it just means you are
> committing to seeing it first and passing the buck to somebody.  gotom has
> volunteered to do triage, and so any report that lacks adequate information
> in the common ways can just be reassigned to him for the usual feedback and
> verification.  If you really don't want to see any report before it's been
> vetted, gotom can be the owner of your component in the system.  But there
> is plenty of work already entailed in what he has volunteered to take on
> for us.

This is fine.

> If you are listed below, please reply to ACK your assignment.  Or NAK if
> you find anything wrong with the list of components here, or don't want to
> be on record as a component's owner.  I would like to get this agreed to
> ASAP so we can start using the system.  Components can be added or removed
> later, so it's fine if all this is tentative.  It might get hairy to remove
> or rename one once bug reports exist.  But it should never be a problem to
> add more later and reclassify bugs under the new distinctions, so we don't
> need to think too hard about this ahead of time.

Btw. are we setting up a mailing list like gcc-bugs that gets all
bugs?

>
> admin:			roland
>   (Web pages, bugzilla, etc.)
>
> libc:			gotom
>   (Catch-all and default place for triage.)
> faq:			aj

Ok.

> hurd:			roland
> linuxthreads:		jakub
> localedata: 		pere
> manual: 		roland
> nis: 			kukuk
> nptl:			drepper
> regex:			jakub
>   (These I presume are self-explanatory.)

We should add architecture specific bugs and the usual port
maintainers as default.

Also I suggest to add:
math (libm): aj
nscd: kukuk


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-hacker/attachments/20040120/f0e3d35a/attachment.sig>