Dogtag Trac Instance#
The Dogtag PKI project uses Trac for tracking all development work (bugs, new features, etc.). Our Trac instance is hosted by fedorahosted.org, so anyone with a Fedora Project account can file new tickets.
Register a Fedora Project Account if you don’t already have one
Access the Dogtag Trac instance
Bugzilla Bug Database#
Bugzilla is our old way of tracking bugs and new development work. We now use Trac as described above. The below links to Bugzilla can be used to see information about old bugs:
Security Vulnerabilities#
If you believe you have discovered a bug which has possible security consequences please let us know. You can enter security sensitive bugs in bugzilla (making sure that the “Security Sensitive Bug” permission option is checked) or by direct contact to the Security Response Team.
How to Write a Bug Report#
The better the bug report the more likely the bug will get fixed. What makes a good report?
See if the bug already exists#
Before entering a new bug do a quick search of existing ones to see if you have found a known issue/problem.
Provide clear and minimal steps to reproduce the bug#
Certainly there are unexplained problems with software but often one can cause the bug to happen upon command. If this is the case, in as few steps as possible, clearly describe what you are doing. If this includes some specific data, include that as well (possibly as an attachment).
If you do have an unexplained crash, include as much information as possible as to what was going on: Was the server under load? How long had it been running? Did you run out of memory? Was the machine doing anything else at the time?
Describe the problem well#
This includes the ticket “Summary” field. “Server crashes” isn’t a particularly descriptive title.
Include only one issue per bug report#
This is for your benefit and for the developers. It will help ensure that things don’t slip through the cracks.
Other things you might want to include#
Snippets from the server error log
Snippets from the server access log
truss or strace output of the server process
stack trace (from a debug build)
How a Source Code Bug gets Fixed#
Presuming that the existing bug report is clear and concise, these steps will be followed when fixing a source code issue.
Bug Assignment#
Once an engineer has decided to work on a particular problem, the Trac ticket is moved from the “new” state to the “assigned” state.
Code Changes#
The engineer fixes the bug in their own tree performing whatever tests are necessary to prove that their fix is valid. Additionally, presuming that the source code change will be made to a particular component, the engineer must update the release number and add a descriptive changelog message to the appropriate spec file(s). The engineer should then create an “svn diff” file which contains all source code and spec file changes, and place this diff file as an attachment to the bug report. No source code may be checked in to the official repository at this time!
Code Review#
The engineer must then ask another colleague to review their source code changes by having that individual review the attached diff file, and document any changes necessary. This process continues until the source code change is accepted, until finally, the reviewer provides their approval in the bug report by attaching something similar to this:
`` attachment (id: 301315) +``
Source Code Checkin#
Once all changes to a given bug report have been approved, the engineer should perform a final subversion update on their tree to insure that all conflicts have been resolved:
`` svn update``
Next, the engineer should execute the following command and place the output into the bug report:
`` svn status | grep -v ^$ | grep -v ^? | grep -v ^P | grep -v ^X``
Finally, the engineer should execute the following command providing a subversion log message which references the bug number and purpose, and place the output of this command into the bug report:
`` svn commit``
Lastly, the engineer should move the ticket status from “assigned” to “fixed”.