This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

bugzilla for glibc: let's get moving!


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]