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