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:
  • Juju-GUI
  • MAAS
  • Cloud init
  • Cloud Images

Juju versions

• Bugs related to Juju 1.x are tracked in "juju-core" project in launchpad.
  • Juju 1.25.x is the latest version available in this series.
  • This project only accepts Critical bugs.
• Bugs related to Juju 2.x are tracked in "juju" project in launchpad.

See if it is a dup

• A quick launchpad search should suffice.

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/lxd) 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, ask for the missing information in the bug 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
    • Critical bugs should probably be added to the bug tracker board and brought to the leads' attention.
  • 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
• Target series:
  • "juju" should always be present as the series for the current development release
  • Use "Target to series" to add the release where bug was found
  • Use "Target to series" to also target other versions (for e.g. a bug reported against 2.0.x will also target 2.1 as well as "juju" to reflect 2.2)
• Tag as appropriate.
  • Tags should be used to get a quick view of bugs of a certain class. i.e. "usability" or "destroy-controller".
  • "eda" = Escaped Defect Analysis. Add it to bugs that come from outside of QA and could have been caught by functional tests. QA regularly review these bugs and add tests where needed.