bugzilla for glibc: let's get moving!

bugzilla for glibc: let's get moving!

[Roland McGrath]

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.

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.

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.


admin:			roland
  (Web pages, bugzilla, etc.)

libc:			gotom
  (Catch-all and default place for triage.)

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



Thanks,
Roland

Re: bugzilla for glibc: let's get moving!

[Andreas Jaeger]

[-- Attachment #1: Type: text/plain, Size: 3796 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: bugzilla for glibc: let's get moving!

[Roland McGrath]

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

http://gcc.gnu.org/bugs.html says lots of useful details about how to write
a good bug report.  If someone wants to write up text like that for libc,
that would be great.  If something really useful is written up, it should
probably go in the Reporting Bugs node in the manual (install.texi) as well.
I don't really have time to do that writing.

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

I will inquire about this.

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

This is a possibility.  There is also the "host triplet" field in bug
reports.  This is something you can do selective queries on easily enough.
When triage verifies that a bug is machine-dependent, the bug could just be
assigned to the canonical person for that port.  I am not really against
adding per-machine components, but I'm not sure it's what makes most sense.

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

Good ideas.


Thanks,
Roland

Re: bugzilla for glibc: let's get moving!

[Andreas Jaeger]

[-- Attachment #1: Type: text/plain, Size: 1596 bytes --]

Roland McGrath <roland@redhat.com> writes:

>> 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.
>
> http://gcc.gnu.org/bugs.html says lots of useful details about how to write
> a good bug report.  If someone wants to write up text like that for libc,
> that would be great.  If something really useful is written up, it should
> probably go in the Reporting Bugs node in the manual (install.texi) as well.
> I don't really have time to do that writing.

So, let's ask for some volunteers ;-)

>> Btw. are we setting up a mailing list like gcc-bugs that gets all bugs?
>
> I will inquire about this.

Thanks.

>> We should add architecture specific bugs and the usual port
>> maintainers as default.
>
> This is a possibility.  There is also the "host triplet" field in bug
> reports.  This is something you can do selective queries on easily enough.
> When triage verifies that a bug is machine-dependent, the bug could just be
> assigned to the canonical person for that port.  I am not really against
> adding per-machine components, but I'm not sure it's what makes most sense.

Then let's go first without it and later see whether we need it...

>> Also I suggest to add:
>> math (libm): aj
>> nscd: kukuk
>
> Good ideas.

Fine,
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 #2: Type: application/pgp-signature, Size: 188 bytes --]