Triaging Bugs

Main steps for bug triage

Make sure it is a juju bug

• Bugs against charms should be marked as "Also affects distribution / package"
  • Select the "Juju Charms Collection", then the appropriate charm
• Documentation bugs are tracked as issues in github: https://github.com/juju/docs/issues
  • You can open the doc issue, then mark the launchpad bug as invalid, referencing the issue you created (if it was a juju core dev that opened the bug, you can kindly direct them to open the doc issue themselves :)
• Other common projects are:
  • MAAS
  • Cloud init

See if it is a dup

• A quick launchpad search should suffice. Cheryl will usually catch dups because she Sees All (like the eye of Sauron)

Make sure the problem is well defined

• Are there recreate steps? An error message or actual vs expected behavior?
• What version of Juju?
• What provider?

Is sufficient information present such that someone could pick up the bug for analysis in a few days (weeks)?

• Logs relevant to the problem:
  • Container issues (lxc) should include logs in /var/lib/juju/containers/* on the host(s)
  • State server / controller logs with DEBUG if possible
  • Unit logs
  • /var/log/syslog for database issues

If there's not enough information either in the problem description or insufficient logs are attached, asked for the missing information and mark the bug as "Incomplete" until the requested information is provided.

Set status and importance

• Set the status from "New" to "Triaged" if it is a juju bug and it has enough information
• A general guideline for Importance:
  • Critical - We cannot ship the next release without this problem fixed.
    • Regressions
    • Loss of functionality with no workaround
  • High - Should be fixed in the near future.
    • Loss of functionality with difficult workaround
    • Barriers to adoption
  • Medium - Would be nice to fix
    • Annoyances (messages, weird kludges to get juju to do what you want)
    • Bugs that have a clear, easy workaround
  • Low - Minor papercuts, "would be nice if juju..."
  • Wishlist - Clear requests for new functionality

Set milestones and tags

• Not all bugs should be targeted to a milestone
  • All critical bugs should be targeted to the next milestone for the release
  • High bugs should be evaluated:
    • Stakeholder bugs are generally targeted to the next milestone
  • Generally, Medium and Low bugs are not targeted to a milestone
• "juju-core" should be used as the series for bugs against the current development release (2.0 right now)
• Use "Target to series" to also target to released versions (right now 1.25)
• Tag as appropriate.
  • Tags should be used to get a quick view of bugs of a certain class. i.e. "usability" or "destroy-controller".