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 discipline


If you're on the cvs or bugzilla tracking mailing lists you might
have noticed some flutter from me tweaking the tracking scripts
tonight.  The script that records cvs commits now indeed looks for
"[BZ #nnn]" strings.  (It also matches several other forms as used
in GCC logs, but "[BZ #nnn]" is the convention we've chosen and
should stick with.)  When a log entry contains this, the same
information sent to glibc-cvs@sources.redhat.com is added as an
annotation to glibc bug
#nnn in bugzilla.

In light of this new facility for tracking, I would like to
propose a bit of discipline that will help us get the most benefit
from it in the long run.  People are already using the convention
of putting "[BZ #nnn]" at the top of log entries.  I would like to
see more of the log entries with those tags, which is to say, more
issues tracked in bugzilla.

Any time you want to contribute a patch that fixes a problem a
user ran into, it should have a bugzilla entry filed for it and
the patch you post should have the [BZ #nnn] tag to show it.  Now,
I'm not saying every single change will have a bugzilla entry--of
course not.  The developers who have direct commit access find and
fix bugs daily, especially when code is changing, and we are not
going to file reports for every little thing.  Nor need other
contributors posting their patches here, when fixes simply arise
in the course of development.

However, when a bug has been spotted "in the wild", i.e. affected
a real user, even one using a test release of a system
distribution, then it should probably have a bugzilla report--most
especially if the bug exists in an existing released libc version.
Copying information from, and/or referencing, your own
distribution's bug-tracking system is entirely appropriate.  It's
worthwhile to have the problem report in glibc's bugzilla so that
any user who comes across the issue in the old release can find
the old report (or a bug triager can resolve their report as a
duplicate, pointing them to it).  The changes that fix the problem
will be automatically logged in the bug report, and users from any
corner can figure out where that fix is available to them.  If an
issue is tracked in your own system and you want to contribute
your efforts to fixing it, then you owe it to the rest of the
community to contribute some effort towards keeping it usefully
tracked in the shared system as well.

Fixes are fixes, so when patches and log entries are correct we
are unlikely to turn them away just for lack of a bugzilla entry
even if the issue clearly merits one.  But please work with us on
this.  Building into the bugzilla database the knowledge of how we
have found and resolved problems is something all concerned can
contribute to, and that, over the long haul of maintenance in
years to come, will optimize all our lives.


Thanks,
Roland


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