Progress towards topic-quantal-defect-analysis
This page shows the progress towards completing a Topic . You can see from the burndown if the Topic is likely to be completed at the current rate of work. Below that you can see the progress towards the blueprints that contribute to the Topic , and the progress of each person working on the Topic .
Launchpad pageWorkitem burndown
"foreign" counts refer to workitems that are assigned to someone not in the team
95% of 42
Contributing Blueprints
| Blueprint | Completion | Priority | Status/Description |
|---|---|---|---|
| foundations-q-more-agile-sru-process |
100% of 7
|
Medium | Our current SRU process is perhaps slightly over-engineered as a reaction to the fact that out previous SRU process was almost certainly far too lightweight. While there's (I hope obvious to all) value in documentation, audit trails, regression testing, and "bake-in" periods, our current process makes it somewhat difficult to get urgent fixes out quickly, while also discouraging the casual observer with an "obviously-correct" 2-character patch from making contributions to stable releases. We don't want to throw the babies out with the bathwater here, but we need to discuss ways we can make the process more agile while still keeping it robust enough to avoid making serious mistakes along the way. |
| other-q-defects-dashboard |
71% of 7
|
High | Rationale: This is a revival of https://blueprints.launchpad.net/ubuntu/+spec/other-p-bug-dashboard. We have lots of sources of information about our packages and bugs, and issues potentially unreported (with whoopsie-daisy). We need to consolidate this information and make it available in a palatable way, so we can worry about what to do to fix and avoid bugs, instead of worrying about how to figure out where to look to check for issues. Goal: Have a centralized place to do a health check of Ubuntu. We want, in a glance, to be able to know packages that have spikes in bugs, bugs that should be fixed but aren't getting the proper attention, problems that are happening but no bugs were reported yet, and the like. |
| other-q-release-bug-list-workflows |
100% of 6
|
Essential | Bugs should be assigned to the teams in order to get them considered for fixing as part of a release (stable,development). However our current infrastructure gives us no effective way of telling the difference between bugs that the development team is not committing to fix, and ones they haven't looked at yet. This causes inefficiencies, and doesn't scale well for teams (release, support, etc.) that have to look at wide range of bugs and issues across multiple development teams. This session is to discuss and agree on some conventions/policies/and possibly additional tooling to make this effective for all the stakeholder, for q development release, and p lts supported release. |
| other-q-bug-report-shadow-database |
100% of 7
|
High | Rationale: Multiple teams are working on reports using .json files obtained from Arsenal. We're looking for a better way to maintain a stateful, historical bug database without stressing the launchpad server. Goal: Agree in a way of persisting launchpad data "locally", being that the source of data for reports. Implement that. |
| other-q-bug-agents |
100% of 7
|
Essential | Rationale: We have lots and lots of bugs filed on a daily basis, bugs that could, given a set of heuristics, be automatically triaged. By triaged we mean flagged as important/unimportant. We want to do that with some level of certainty, to avoid missing important reports but removing the need of manually triaging every single bug filed against Ubuntu packages. Goal: Have a script or a set of scripts that automatically do the first round of triage, removing useless or not likely to be useful bug reports, and raising the priority of the potential issues whenever they happen. Remove the need of worrying about triaging all bugs and let us focus on fixing the important ones. |
| qa-q-isotracker-testcases |
100% of 8
|
High | Discussing expanding the isotracker to perform testcase management and reporting for all kinds of testing, not just iso. |
Status by assignee
| Assignee | Todo | Blocked | In Progress | Postponed | Done | Completion |
|---|---|---|---|---|---|---|
| all | 0 | 0 | 0 | 0 | 2 | 100% |
| arges | 0 | 0 | 0 | 0 | 5 | 100% |
| Brian Murray | 0 | 0 | 0 | 0 | 8 | 100% |
| Daniel Holbach | 0 | 0 | 0 | 0 | 1 | 100% |
| Evan Dandrea | 0 | 0 | 0 | 1 | 0 | 100% |
| Kate Stewart | 0 | 0 | 0 | 0 | 4 | 100% |
| komputes | 0 | 0 | 0 | 1 | 0 | 100% |
| Matthew Paul Thomas | 0 | 0 | 0 | 0 | 1 | 100% |
| Stéphane Graber | 0 | 0 | 0 | 1 | 7 | 100% |
| Ursula Junque | 0 | 0 | 2 | 1 | 3 | 67% |
| Steve Langasek | 0 | 0 | 0 | 0 | 5 | 100% |
Work item details
| Assignee | Status | Blueprint | Priority | Work item |
|---|---|---|---|---|
| all | done | other-q-bug-agents | Essential | Follow the list of bugs "selected" by gravity for ~ a month, check if the heuristics are working, if we're missing other issues important as well |
| foundations-q-more-agile-sru-process | Medium | follow up in the phased deployment session about whether we can gather information from whoopsie about -proposed packages that are *not* crashing | ||
| arges | done | other-q-bug-report-shadow-database | High | (brian-murray james_w) Look at launchpad code, look at database generation .sql file. |
| other-q-bug-report-shadow-database | High | - investigate bug-timetracker/quality-dashboard to see if this code is what we need | ||
| other-q-bug-report-shadow-database | High | - start writing script to grab data from launchpad | ||
| other-q-bug-report-shadow-database | High | - determine what machine/software requirements are needed (if any) | ||
| other-q-bug-report-shadow-database | High | setup project under arsenal - name shadow-database | ||
| Brian Murray | done | other-q-bug-agents | Essential | Hack in the retracers to point to the newest release bug if it's a duplicate of an old bug (add the latest release to the tags of the master bug report) |
| other-q-bug-agents | Essential | copy latest release tags from duplicate apport-crash bugs to the master bug | ||
| other-q-bug-agents | Essential | make the apport-retracer set the importance of python crashes to medium | ||
| other-q-bug-agents | Essential | set existing python tracebacks in Launchpad to Medium | ||
| other-q-defects-dashboard | High | modify searchTasks in Launchpad API to have date_created_since accept a beginning date range so that we can link to the bugs that make up the spike in activity (https://bugs.launchpad.net/launchpad/+bug/826854 ) | ||
| other-q-release-bug-list-workflows | Essential | will create reports once process signed up. | ||
| foundations-q-more-agile-sru-process | Medium | patch sru-accept to link to .debs for -proposed in comment or the page of the binary package build in launchpad which has all the deb links from the librarian (as the security team does) | ||
| foundations-q-more-agile-sru-process | Medium | Advertise pending-sru.html in sru-accept comment? | ||
| Daniel Holbach | done | foundations-q-more-agile-sru-process | Medium | send pilot scheduling tools to dmitrij.ledkov |
| Evan Dandrea | postponed | other-q-defects-dashboard | High | make information about errors regarding phased updates and proposed packages available via the API |
| Kate Stewart | done | other-q-defects-dashboard | High | get references to meego dashboard as example to look at for mockups |
| other-q-release-bug-list-workflows | Essential | need a plan for flavors, orthogonal mechanism. - possible tag. | ||
| other-q-release-bug-list-workflows | Essential | process pages need clean up - updated RC -bug target needs to be replaced. | ||
| other-q-bug-report-shadow-database | High | (arges) write use-cases / requirements in blueprint | ||
| komputes | postponed | other-q-bug-agents | Essential | Create "agents" to deal with bugs and alert people about them |
| Matthew Paul Thomas | done | other-q-defects-dashboard | High | draw mockups and work with Ursinha to refine <https://dev.launchpad.net/DefectsDashboard> |
| Stéphane Graber | done | qa-q-isotracker-testcases | High | Update DB schema to have testcase entries be one-to-many to testsuite and have testsuite be many-to-many to milestone_series |
| qa-q-isotracker-testcases | High | Never allow modifications to qatracker_testcase | ||
| qa-q-isotracker-testcases | High | 2: Figure out how to manage users roles (per product roles) (use lp teams, grant isotracker roles based on team) | ||
| qa-q-isotracker-testcases | High | add link to report "bug" against problems found on a testcase (bug #684404) | ||
| qa-q-isotracker-testcases | High | 2: come up with development plan for cycle | ||
| qa-q-isotracker-testcases | High | add testcase id that stays unique and persists across revisions | ||
| qa-q-isotracker-testcases | High | Let the team know when (iso.qa.dev.stgraber.org) is ready for testing | ||
| postponed | qa-q-isotracker-testcases | High | implement reading LAVA format on the tracker (http://linaro-dashboard-bundle.readthedocs.org/en/latest/index.html) | |
| Ursula Junque | inprogress | other-q-defects-dashboard | High | Find a design person and request input about how to display all this data |
| other-q-defects-dashboard | High | Create mock-ups and request input from people that will use it - kate, brian, cgregan, ev, bjf, mmrazik | ||
| done | other-q-bug-agents | Essential | Change gravity so that it takes age (and other factors listed in the gravity heuristics list into account (old bugs don't have high gravity, fresh bugs do) | |
| other-q-release-bug-list-workflows | Essential | consider rls-q-* tags when calculating gravity (+ for incoming, - for notfixing) | ||
| other-q-bug-report-shadow-database | High | - investigate proper ORM to use | ||
| postponed | other-q-defects-dashboard | High | Check how to use openid to make access to the bugs restricted. Keep private bugs/crashes in the list, but allow/deny access to them | |
| Steve Langasek | done | other-q-release-bug-list-workflows | Essential | write up proposal based on discussion |
| other-q-release-bug-list-workflows | Essential | check to make sure meets jason's requirements and get manager signoff. | ||
| foundations-q-more-agile-sru-process | Medium | talk to balloons about reviving the SRU verification team | ||
| foundations-q-more-agile-sru-process | Medium | discuss with stgraber, balloons about QA tracker vs. his tools for gathering this information | ||
| foundations-q-more-agile-sru-process | Medium | fix SRU procedure to make the "regression potential" section emphasize areas that need additional testing; obsolete "development fix" in favor of bug tasks |
Last updated: Fri 26 October 2012, 08:48 UTC