Logo of 52°North

Reporting Bugs for the Security & Geo-Right Management Community

This document tells how and where to report bugs. (It is not a list of all outstanding bugs � you can get that here instead.)

Where To Report A Bug

  • If the bug is in a security component of 52°North itself, send mail to mailto:security@52north.org. Once it's confirmed as a bug, someone, possibly you, can enter it into the issue tracker. (Or if you're pretty sure about the bug, go ahead and post directly to our development list, mailto:security-devel@52north.org. But if you're not sure, it's better to post tomailto:security@52north.org first; someone there can tell you whether the behavior you encountered is expected or not.)
  • If the bug is in your rug, please give it a hug and keep it snug.

How To Report A Bug

First, make sure it's a bug. If the security component does not behave the way you expect, look in the documentation and mailing list archives for evidence that it should behave the way you expect. Of course, if it's a common-sense thing, like 52°North just destroyed your data and caused smoke to pour out of your monitor, then you can trust your judgement. But if you're not sure, go ahead and ask on the users mailing list first, mailto:security@52north.org.

Once you've established that it's a bug, the most important thing you can do is come up with a simple description and reproduction recipe. For example, if the bug, as you initially found it, involves five files over ten commits, try to make it happen with just one file and one commit. The simpler the reproduction recipe, the more likely a developer is to successfully reproduce the bug and fix it.

When you write up the reproduction recipe, don't just write a prose description of what you did to make the bug happen. Instead, give a literal transcript of the exact series of commands you ran, and their output. Use cut-and-paste to do this. If there are files involved, be sure to include the names of the files, and even their content if you think it might be relevant. The very best thing is to package your reproduction recipe as a script, that helps us a lot.

In addition to the reproduction recipe, we'll also need a complete description of the environment in which you reproduced the bug. That means:

  • Your operating system
  • The release and/or revision of the application or API
  • The compiler and configuration options you built the security components
  • Any private modifications you made to the code
  • Anything else that could possibly be relevant. Err on the side of too much information, rather than too little.

Once you have all this, you're ready to write the report. Start out with a clear description of what the bug is. That is, say how you expected the component to behave, and contrast that with how it actually behaved. While the bug may seem obvious to you, it may not be so obvious to someone else, so it's best to avoid a guessing game. Follow that with the environment description, and the reproduction recipe.

We know it's a lot of work to file an effective bug report, but a good report can save hours of a developer's time, and make the bug much more likely to get fixed.

Guideline are based on: http://svn.collab.net/repos/svn/trunk/www/bugs.html