Next: , Previous: , Up: Top   [Contents][Index]

17 Bug Reports

Bug reports are a good thing. They show that people are using the code that you spent so much time and effort in writing. Bug reports are an opportunity to improve SXEmacs. Never be scared of bug reports. Never get annoyed or upset by bug reports. Welcome them. As a matter of fact, worry if you don’t see any bug reports. That would mean we aren’t working hard enough. :-)

All bug reports have to be submitted to our Issue Tracker. So it goes without saying that you already have an account on our Issue Tracker, and if you don’t, go get one now.

Because the Issue Tracker is just that, it tracks issues, all followups and correspondence concerning a bug must be added via the issue tracker itself. DO NOT follow up to a bug report on the mailing list. If a bug report is submitted to the mailing list initially (because the submitter wasn’t aware of our Issue Tracker), the person submitting the report should be directed to our Issue Tracker. If they are unwilling or unable to do so, one of us will do so.

If a bug report results in a patch and merge request, the summary of the patch log should contain the text: "(Closes bug #n)", where ‘n’ is the number that our Issue Tracker has assigned to that bug. The bug should be marked as "fixed" (stating in which revision) on the Issue Tracker. It should not be marked "Closed" until just prior to a release. Closing bugs is the job and responsibility of the project lead, or whoever is responsible for making releases.

Next: , Previous: , Up: Top   [Contents][Index]