| Home | Libraries | People | FAQ | More

# What to do about Boost bugs

1. Make sure the bug isn't already fixed in the latest sources. The most recent version of everything on the Boost web site is available from the boost public CVS repository.
2. If you are a Boost user, or a Boost developer that doesn't have a CVS write access:
   1. Submit a bug report to either boost-users list, boost mailing list, or our bug tracking facility at SourceForge; submitting it to either of the mailing lists is a preferred way - because many of the Boost developers read the lists on a daily basis, this way you are likely to get a quicker response, and the discussions that often arise there from (possible) bug reports are quite interesting and educational as well;
   2. If you have a proposed patch to the code, post it along with your bug report, preferably in the context diffs format (`diff -c`); if you can, send a patch relative to the current CVS state. A canonical example of creating a patch file follows (let's assume that you've found a bug in the file `intentional_bug.hpp`:
      1. Download the latest version of `intentional_bug.hpp` from CVS.
      2. Make sure that the bug is still present in the code.
      3. Copy the file `intentional_bug.hpp` to a file called `intentional_bug.hpp.orig`.
      4. Apply your changes to `intentional_bug.hpp`.
      5. Run "`diff -c intentional_bug.hpp.orig intentional_bug.hpp > intentional_bug.hpp.patch`" from the command prompt.
      6. Submit the patch file together with an explanation of the bug and the proposed fix; and don't forget to include the word patch or bug in the subject if you're submitting to the boost mailing list.
3. If you are a Boost developer, and you have a CVS write access:
   1. If the bug is trivial (e.g. misspelled name, missed `typename`, etc.), and you are willing to make a fix, either make your changes locally and contact the library author(s)/maintainer(s) about it, or go ahead and check the fix into CVS, but post a notification about it to the boost mailing list (if the author is not very active on the list, you also might want to consider `cc`'ing him as well);
   2. If the bug is non-trivial, and/or you don't have the time and resources to fix it, submit a bug report (see p. 2 above); chances are that the maintainer(s) will respond promptly and take care of the problem;
   3. Otherwise, create a temporary branch in CVS, make your changes there, and ask the library author(s)/maintainer(s) to review them; if they are ok with the new code, either you or they can integrate the fixes into the main trunk.

Contributed by Aleksey Gurtovoy

Revised 18 January, 2002