Improving Bug States and Workflows

Registered by Allison Randal

Followup on, reviewing results of developer survey, and discussing proposed changes to bug states and workflows.

Blueprint information

Kate Stewart
Ursula Junque
Series goal:
Accepted for precise
Milestone target:
milestone icon precise-alpha-2
Started by
Kate Stewart

Related branches



- A survey was created and an e-mail was sent to ubuntu-devel to find out how people feel about using Launchpad. (44 responses - ~1/4 of Ubuntu Developers) (Note: There are > 2500 subscribers to the ubuntu-devel mailing list). Some results are:
  - People feel they do more manual work than should.
  - Not possible to look at bugs, but better tools could be make it possible to look at them
  - Opinion status is not used
    - Opinion status going away is an open task on Launchpad and is something they want to do
  - People are using tags in way that could be considered as bug state for workflows.
    - Kernel team would like custom per project status.

- In order to work with upstreams better need to have 1:1 mappings with bugzilla states.
  - Definition of the statuses -
  - Definition of how LP translates external statuses to LP statuses: - (can be found in lp source code: launchpad/lib/lp/bugs/externalbugtracker/
- "Incomplete" is sometimes used for fixes that need testing, and then expires when it shouldn't.
  - Expiration can be blocked in a variety of ways, for example by having an assignee
- Consider renaming "Triaged" to "Ready" (or "Ready to Fix")
- Possible removal of states (Opinion, first of them)
- Gentle social pressure towards standardization, by making definitions visibile in the Launchpad web interface.
  - What do bug statuses mean to each Ubuntu development team? For example, QA subloop - fix committed, activate QA states, verification, set to fixed released. It varies.
- Diagram the ideal workflow for each team and how they map it to current representations in Launchpad. Look for the mismatches between the two.
  - Proposal that each of the teams to check against.
  - Interesting cases to consider:
    - SRU flow.
    - Kernel config.

Work Items:
[ursinha] Find and publish notes of the DAs discussion on which parts of the bug workflow are common to all engineering teams: DONE
[ursinha] Create a convention for documenting state diagram for teams workflow currently (similar to this: and and broadcast to workflow documenters: DONE
[ursinha] document server team workflow: DONE
[ursinha] Ask people who work with ubuntu-software-center how they use it as well as they seem to have a yet different bug workflow (requested by mpt): POSTPONED
[brian-murray] document foundations team workflow: DONE
[ursinha] work with pvillavi to document desktop team workflow: DONE
[jsalisbury] document kernel team workflow: DONE
[bryce] document X-Team workflow: DONE
[cgregan] document CE team workflow: DONE
[ursinha] document SRU bug workflow: DONE
[kate.stewart] Organize followup meeting half-way through the cycle to review the differences between teams.: DONE
[ursinha] First draft unified workflow. This workflow should look at bug assignment as a part of it as people seem to use assignment differently: DONE
[kate.stewart] Discuss in the next Thunderdome/Rally with Launchpad about the common workflow we have so far and figure out improvements: POSTPONED
[flacoste] Will discuss how to implement the user needs from the proposed common workflow.: POSTPONED


Work Items

Dependency tree

* Blueprints in grey have been implemented.