Launchpad Entry: ubuntutheproject-foundations-n-improved-support-declarations
Created: 2010-10-22
Contributors: Emmet Hikory
Packages affected: software-centre, python-apt, synaptic, muon
Summary
In preparation for the implementation of ArchiveReorganisation/Components, we need a richer interface for declaration of "supported". There are two current methods by which support is indicated: firstly each package may have a Supported: status indicating whether it will be provided with 18, 36, or 60 months of security support by the Canonical security team, and secondly many of the package management tools (including comments in sources.list) use separation by component to declare support by Canonical.
A richer interface should allow arbitrary (authorised) parties to declare support for arbitrary terms for arbitrary sets of packages, with package collections based on (potentially overlapping) packagesets or other types of list, rather than on component.
Release Note
Ubuntu package managers are now able to accurately reflect which organisations or communities support various packages.
Rationale
Lots of different folk support different packages in Ubuntu in different ways. As discussed as part of Archive Reorganisation, there is no longer a close relation between that supported by Canonical and that in the "main" component, nor is there any way for other organisations participating in Ubuntu to indicate support for software explicitly supported in Ubuntu. We should fix this, so users can have an accurate understanding of whether they should expect support for a given piece of software, and so that our support teams can better understand what software is supported by *someone*, rather than just allowed to build, untested.
User stories
- Alice uses Kubuntu, and wants to ensure that all the packages she installs are supported by the Kubuntu community.
- Bob works for a software company and wants to make sure Ubuntu users of his software know it has full support in Ubuntu.
- Chris has a support contract with Canonical and wants to know if a specific package is supported.
- Dora is a solutions provider, delivering Ubuntu as the solution, and wants to indicate a set of packages she supports for her customers.
- Everett is concerned about the security of his system, and needs to know which packages are assured of security updates if vulnerabilities are discovered
- Francis works for a silicon vendor and wants to declare support for certain hardware enablement utilities in Ubuntu.
Assumptions
- Support declarations may be public or private
- Support organisations may be structured or unstructured, statutory or transitory
Design
Similar to software channels, support declarations are made by adding files to the filesystem in a structured format, declaring a set of packages, the level of support offered, and the organisation providing that support. Package management tools that display support information parse available files to present this information. Possible issue is the invisibility of support declarations if the appropriate support package is not installed.
*OR*
Additional overrides are added to the repository to add a more complex Supported: header. Possible issue is the inability to provide private or out-of-archive support guarantees.
*OR*
Your cool idea here.
Implementation
TBD
UI Changes
TBD
Code Changes
TBD
Migration
Supported: header
Packages with the "Supported:" header need to be reviewed to determine what organisation(s) support them, and appropriate declarations constructed
packages in main
Packages in "main" need to be reviewed to determine which receive "support", and by what organisation: these details need to be converted into support declarations.
Test/Demo Plan
A first-pass review of initial support declarations should be compared to the Supported: headers and the content of the "main" component to verify they match current expectations.
A sample additional support declaration should be added to demonstrate how this works (extra points for being real)
Unresolved issues
- Approval process for in-archive support declarations
Anything related to ArchiveReorganisation not directly connected to the semantic value of "supported"
- Identification of potential support providers
- How to handle private declarations.
- What is security providing support for? make sure they understand debtags are sufficient?
BoF agenda and discussion
- What makes sense as a design?
- master approach on mirrors
- public vs. private declarations (restrict to public initially)
- public use cases to consider
- canonical support contract,
- revolution OS declares which features are supported,
- what Kubuntu is getting support for some period of time.
- think of interms of security, maintenance, and help/consultation.
- representation in packages file is reasonably compact.
- overrides, 6,12,18...
- definitions for the release support auto propigated to the contents of the seeds that were part of the release.
- master approach on mirrors
- If we select packages, how do we deal with potentially absent declarations?
- we've selected overrides (debtags) so not issue.
- If we select overrides, how do we deal with private declarations?
- defer until after we've architected public, remote debtags source, wait until after we have someone who needs it.
- Should support declarations be packagelists or packagesets? If packagesets, should they be required to be seed-based (and recursively closed)?
- will approach as packagelists initially.
- Which package managers need to show this information
- is debtags rich enough to express this? use this for first pass, and then after some base cases established, then see if we need to extend debtags.
- How should support declaration data be structured? Stored?
- what does supported by information look like - may be something similar to "maintainer"? company name, web site, period of support.
- overrides of public declarations this cycle
- try to not break the private use case
- Ubuntu Support Center will need to understand debtags, then put it into other interested interfaces. Who will use such a system? outreach, or will likely see volunteer? likely will come, use this as base assumption.
Actions
- [persia] digest list and update notes, review with Colin and Micheal
- [persia/skaet] make proposal to ubuntu-devel with debtags taxonomy