Review the bug lifecycle states and Ubuntu developer usage
When surveying development team behavior while putting out Natty, there were different "best practices" that were uncovered, that were not consistent between teams. This results in it being hard to get consistent understanding of the state of the release across various projects.
This session is to discuss the current bug states, ambiguities, and explore options to improve the common understanding of use of bug states, and consistency.
Blueprint information
- Status:
- Not started
- Approver:
- Kate Stewart
- Priority:
- Undefined
- Drafter:
- Kate Stewart
- Direction:
- Needs approval
- Assignee:
- Jonathan Lange
- Definition:
- Drafting
- Series goal:
- Proposed for 11.12
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
Whiteboard
Work items:
Work items for oneiric-alpha-1:
[allison] WIKI page to create survey questions: DONE
[allison] get contacts identified for participants in this bug workflow review: DONE
[allison] structured location set up for use case raw input: DONE
Work items for oneiric-alpha-2:
[allison, brian-murray] create survey from questions: DONE
[allison] Launch survey to stakeholders (ubuntu-devel, lauchpad-users, top 5 consumers of bugs, oem team): DONE
[allison] review existing tags and cross check with use cases: TODO
[jml] set up LEP page for summarizing use case results: DONE
Work items for oneiric-alpha-3:
[jml,allison,
[jml,allison,
[allison, brian-murray] plan for standardizing our current workflow and tags for Ubuntu.
Work items for oneiric-beta-1:
[jml] review new bug states with stakeholders.
[jml] produce plan for transition to new bug states (timing, documentation, etc.)
[allison,
Work items for oneiric
[jml] - shedule review of plans at UDS-P for bug state transition and incorporate feedback
-------
Basic flow to intersect with the Oneiric cycle...
Alpha 1 - Set up analysis
Alpha 2 - Find out how bugs are currently used. (Gather requirements)
Alpha 3 - Analyze data and come up with proposals
Beta 1 - First round of feedback on solutions and setting up plans for bug lifecycles.
UDS-P - Review plans with wider community for input
== UDS session notes ==
GOAL: By oneiric release, have a clear picture of what states & workflows we want on Launchpad.
* Review of practices around bugs
* Upstreams
* Ubuntu packages (kernel, apps)
* inconsistencies between teams
* lack of a testing state in Launchpad
* Needs re-tested against current development version (oneiric) vs. stable release (maverick/natty)
* Needs re-tested against upstream kernel (mainline kernel snapshots)
* Pre-commit patch needs tested to see if it fixes issue
* Pre-commit patch needs tested to see if it causes any regressions aside from the fix
* Post-commit fix needs validated that it did indeed fix the original problem
* Post-commit fix needs verified that it isn't causing any regressions
* Confusing states: Incomplete with(out) answer, Invalid/Opinion, Confirmed/Triaged and FixCommitted/
* with/without answer is useful to track in general, currently we set bugs to Incomplete even when they're not really Incomplete, so we can utilize this 'answered' feature of the Incomplete state.
* Tags used for tracking workflow "next action" states - 'needs-retested', 'needs-
Need to get a picture of the whole lifecycle for Ubuntu bugs. Need to get input from many different parts of the Ubuntu project.
Bugs yet to be filed:
* See that a bug is incomplete *with response* vs *without response* on a list
* See that a bug is incomplete "with response" vs "without response" on a bug's
page
* Bug statuses should be documented within Launchpad
* especially where they are used on a bug page / lists
Use case:
* As a developer, I need to see bugs that I think are fixed but need user testing so that ____
* As a developer, I want to see a list of bugs with replies to requests I've posted (clarification needed from reporter, testing needed, etc.)
Workflows:
* There are bugs that need fixing in multiple different projects before the bug can be considered fixed at all. The secondary project should be able to more easily see that the issue is waiting on them and has already gotten fixed in the primary project; currently such situations have to be handled out of band or get lost in the noise of 6000 kernel bugs.
Going forward:
* Launchpad very happy to work with external contributors to solve (& also get clear on) these difficult problems
* It will probably be more difficult than Ubuntu devs think, because there are many other classes of users & stakeholders on Launchpad
* Maybe there will be a change of workflow in Ubuntu as well as a change in Launchpad
* Use cases are awesome: As a $ROLE, I want to $DO_A_THING, so that $MEASURABLE_BENEFIT
* <lifeless> skaet: there are tonnes of designers around: what we need mainly is problem statements we can fit the huge number of existing (and future) proposals against.
mpt's suggestions[1]:
Unconfirmed: Not yet investigated by someone qualified to determine its coherence.
Declined: Not appropriate or relevant for this project.
Incomplete: May be appropriate, but is missing information about the precise problem — for example, reliable steps to reproduce, a testcase, or hardware details. Would be nice to tabulate a list of info is needed.
Ready: The issue is described well enough, and is approved if necessary, so that work can begin. (Cf. BugzillaWorkflo
In Progress: Actively being designed, implemented, or fixed. (Some projects and/or assignees may not bother with this status.)
Done: Fixed, implemented, or achieved. Any unresolved issues have been recorded separately. For versioned things (such as software), the version/versions in which the issue is resolved should be recorded.
“New” -> “Unconfirmed” (because “New” is misleading)
“Invalid” -> “Declined” (because “Invalid” is needlessly harsh)
"Won't Fix" -> "Declined"
“Opinion” -> “Declined” (because something being a matter of opinion is orthogonal to whether the maintainer will accept it)
“Confirmed” -> “Unconfirmed” (superseded by users-affected count)
"Triaged" -> "Ready" (because the name "Triaged" is both misleading and over-specific)
"Fix Committed" -> "Done" with "context-
"Fix Released" -> "Done" with "context-
ttx suggestion:
There is no way we can find a set of statuses that will match everyone's workflows, but there is value in a common set of canonical statuses. One way to solve it is to use a global simplified status (mpt's list) with a per-project configurable list of substatuses that will map the workflow of the project. Declined +opinion. In Progress +needstesting. That substatus would show in bug searches, be more than a simple tag.
Use case: As an upstream project QA dude, I want to be able to select a substatus to further precise the status, so that I can use LP as a full workflow tool rather than just a collection of bug data with loosely-appropriate status
vorlon: I am probably in a minority here, but I prefer to retain the distinction between invalid and wontfix because in some cases it's useful to signal that a bug won't be fixed due to resourcing, as opposed to it not being a bug (--> invalid) Agreed (bryce)
References
[1] https:/
* https:/
* https:/
* https:/
* https:/
* https:/
* https:/
* https:/
ACTIONS:-
allison to survey what the use cases are across the involved communities and get contacts identified.
- put together a WIKI - to gather other's questions for the survey
- standardize on input format, diagramatical notation, so we can explore consistent.
jml- where to store use-case --- LEP
- summarize out common states, and definitions
- states, transitions, and DEFAULTS ;)
- feed back to teams to get their input if states work for this.
- will probably get bigger before it gets broken up into smaller chunks
- survey ubuntu-devel and launchpad-users - cross post. Find out who wants to be involved.
- actively contact top-5 consumers of bugs to make sure the largest upstream projects are involved
- get a proposal of what the states are that should satisfy the use cases
- get defaults on creation - cases to consider: per series; per multiple packages in series to fix a bug
GOAL: By oneiric release, have a clear picture of what states & workflows we want on Launchpad.
Work Items
Dependency tree
* Blueprints in grey have been implemented.
