Managing DistroRelease-Updates and DistroRelease-Security
Status
Created: 21/04/05 by MarkShuttleworth
Priority: HighPriority
People: DanielSilverstoneLead, JamesTroupSecond
Contributors: MarkShuttleworth, AdamConrad
Interested:
Status: BrainDump, BreezyGoal, UduBof, LaunchpadSpecification
Branch:
Malone Bug:
Packages:
Depends:
UduSessions: 8
Brain Dump Notes
- Add in the concept of "Pockets"
- A pocket is a sub-distrorelease
- E.g. hoary-security is the "SECURITY" pocket of hoary
- Fix up SPPH and PPH to do this. (Depends on PPH work)
- Dominator needs pocket support
- Publisher needs pocket support
- Flavours don't interact with pockets other than that their component changes should affect the pockets too.
Introduction
This spec describes how we intend to handle breezy-updates and breezy-security in Launchpad. We need to discuss this and evolve this document into a specification for implementation. I've budgeted 8 sessions for this as it's potentially a further complication on top of PackagePublishing and needs to be considered and drafted very carefully. It's high priority as it's an essential part of the ability to publish an actual distrorelease using Launchpad, and will be required for derivatives.
Rationale
Scope and Use Cases
Implementation Plan
Data Preservation and Migration
Packages Affected
User Interface Requirements
Outstanding Issues
Should these be separate distroreleases or extra subtleties of publishing? MarkShuttleworth: I think it should be intrinsically part of the publishing process rather than a separate distrorelease.
- Can we use some of the ideas in overlay derivative distroreleases for this since they end up looking very similar? Or can we actually combine those ideas completely so that these really *are* overlay distroreleases?