wiki:TicketWorkflow

How to Create Boost Tickets

If (heaven forfend) you find a problem in Boost, the best way to get it noticed is to file a Trac ticket. Posting on the mailing lists is great for getting attention, but things get lost there.

When creating a ticket, make sure that you do the following:

  • Set your email address in "preferences" first. Almost certainly, the author of the library will ask you for more information. If you don't include an email address, there is no way to contact you.
  • Indicate the version of boost that you are using, along with the OS/compiler combination. If you are using any custom libraries as well (STLPort, say), please mention them.
  • If you know the maintainer of the library that you are submitting the ticket against, please set the owner. Here is a list of maintainers.
  • Choose the bug type carefully:
    • Bugs - something that should work doesn't.
    • Feature Request - something that you think the library should do, but it currently does not.
    • Patches - Please don't use the "Patches" bug type. If you have a patch, that's great. Attach it. But mark the ticket as either a "bug" or "feature request".
    • Support Requests - another unused ticket type. Support is better handled on the mailing list.
    • Library Submission - if you have a library to submit, contact the review manangers to arrange a review.
    • Tasks - rarely used, mostly by library maintainers to make sure they don't forget something.
  • Severity - how bad is this ticket?
    • Showstopper - this problem is so bad, that we should hold up a release if it's not fixed. Note that the release managers and/or the library maintainers may have different opinions.
    • Regression - something used to work (in a previous release), but no longer does.
    • Problem - the default value.
    • Optimization - this makes the library work better (usually with a patch enclosed).
    • Cosmetic - minor problems, like using the wrong "they're/there/their" in a comment, or a typo in the documentation. Do not be discouraged from creating tickets for "minor" issues like this. They're easy to fix, and they make boost better.

How to Handle Boost Tickets

As of this writing, Boost has lots of open tickets. Here are some effective things you can do to help close them.

  • Make sure tickets can be assigned to you: Tickets cannot be assigned to you unless:
    1. you have an account that lets you log into this trac and gives you write access to our Subversion repository. Send email to boost-owner@… to get an invitation
    2. you have entered your email address in Trac (see the “settings“ link that appears in the upper right of this page once you've logged in).

  • Accept tickets that are assigned to you: this shows that you've looked at the ticket and acknowledged the issue as your responsibility.
  • Get the Reporter on the Notification List: make sure that you know who reported the problem. If their email is on the ticket, then great - they'll be notified every time the ticket is updated. If not, then your conversation with them may be intermittent.
  • Fix the Bugs that are Assigned to You. (Duh!) If you're logged in, here they are, in order of decreasing priority. However, if your SourceForge UserID is not the same as your Trac UserID, you may have a whole slew of other open tickets. See this report for all the owned tickets sorted by their original owner IDs. Subversion tip: when you commit a change to Subversion that fixes ticket number NNN, include the text "Fixes #NNN" in your commit log. Trac will automatically close the ticket and cross-reference the commit with the ticket.
  • Triage Unassigned Tickets. report:10 shows all tickets that haven't been assigned to real developers.
    • Assign Component and Owner: Set the ticket's “component” field to the right library and assign the ticket to the maintainer of that library.
      • If the right library doesn't appear in the “component” menu, send an email to boost-owner@… requesting that it be added.
      • If you can't find an obviously-correct owner, try to put the maintainer's email address in the Ticket's Cc: list.
        (Probably someone needs to start a Wiki page that identifies Boost library maintainers by their Trac/SVN ids.)
    • Close Invalid “Feature Requests”: “Feature requests” that are actually suggestions for new Boost libraries are invalid—as tickets, that is. There's nobody to whom they can be assigned. The reporter should be directed to start a discussion in some forum where a qualified domain expert is likely to be listening, or to this page on the Boost users' wiki, …or you can enter the suggestion there yourself.
Last modified 12 years ago Last modified on Nov 2, 2010, 4:40:36 PM
Note: See TracWiki for help on using the wiki.