Associate all bugs to a series
Launchpad can currently target bugs either at the distro (or sourcepackage) without any series associated, or associate it to a particular release. This model has several drawbacks as it causes confusion (bug 314432) as well as performance problems.
The Launchpad team is investigating the possibility of associating all bugs with a series. This session is to discuss the user impact of such a change, and make sure it's compatible with the distribution workflows.
Blueprint information
- Status:
- Not started
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- None
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- Discussion
- Series goal:
- Accepted for precise
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
Whiteboard
Work Items:
Design review of LEP by stakeholders prior to implementation. Various Ubuntu and Flavor teams: TODO
Design needs to include how to handle End of life of a series on staging and on another series: TODO
Design needs to include how to handle transition from one milestone to another.: TODO
Review versioning of API to make sure we don't break contract with lucid (no need - compabile) (Possibly not. Ubuntu believes most reported bugs are against the stable series, not the focus of developent; to preserve the API, the reported bug needs to go to the last stable series AND/OR createBug(
Get input on the question if: The distro/
= session notes =
https:/
https:/
User interface issues because we do not correctly report bugs that are in the series.
Security: CVE comes in, against project, not series, upstream fixes, not clear what CVEs.
Must be able to change series after its been reported. Its in the project/package. Default is against its a current series.
Important to make sure the defaults for a series make sense, and avoid manual busy work.
This will end conjoined bugs - live independent.
One task per series in the bug.
Private bug can only have tasks on one pillar (project or distribution)
Transistion from one series to next (ie. oneiric to precise); remain indefinitely.
Request is to ask if should be copied into new series and what defaults should be.
Default for the new series on transition should be to the status and importance of the prior series, NOT New, Undefined, etc. Possibly this might be a question, but at release opening, the status is going to be the last status.
Series selected can ONLY be the active and support series. [this is true today] Just making it explicit. Since a bug opened in Jaunty might still be openend. When we EOL a series, all open bugs against that series should be closed as WON'T FIX.
Retargetting from series to series. Able to delete extraneous lines.
Able to get INVALIDs out of bugs.
Bug dependency mechanism. (duplicates, etc.)
Overloaded usecases:
- project and partner - series definition represents code. Subdiving work and where bug goes.
Bug 857109 is about reporting a bug against an old series
Scheduling this sort of invasive change will need to be handled in conjunction with release schedule.
Maintenance vs. Feature squad issues.
Reporting bug over API would be different. [no change, fully compat - just the returned object will have a series component in the url]
Retarget to obsolete series - will not be possible. [same as today]
ACTIONS:
[] Design review by stakeholders prior to implementation. Various Ubuntu and Flavor teams.
- creative posting to launchpad developer list - turn it into LEP [is a lep already]
[] End of life of a series on staging and on another series
[] End of life from one milestone to another.
[] Review versioning of API to make sure we don't break contract with lucid [no need - compatible] [Possibly not. Ubuntu believes most reported bugs are against the stable series, not the focus of developent; to preserve the API, the reported bug needs to go to the last stable series AND/OR createBug(
[] ADDENDUM: The distro/
Work Items
Dependency tree
* Blueprints in grey have been implemented.
