Derivative Distributions

XXX - more text here

As an OEM provider
I want to make a customized version of Ubuntu
so that I can ship the OS best suited to my hardware

Rationale

Why are we doing this now?

What value does this give our users? Which users?

What MUST the new behaviour provide?

Ability to sync packages, some auto, some manual
model child/parent at series level - 1-many relationship
track state of packages compared to parent's copy
- report of differences against parent(s)
  - what might I want? what do I need to push upstream?
- action on reports: syncing packages in both directions
- sync all packages changed in parent but not changed in child
  - cron job which we can enable/disable in UI, or via an API call
package branches for derived archives/distros
create new derived distro based on packagesets
- QUESTION: who should be allowed to do this?

Nice to have:

What MUST it not do?

Brainstorming:

Ability to push a bug upstream to a parent distribution
Official package branch maintenance for derivatives
Full archive services for these distributions
See the difference between a derivative and its parent
- Which packages are newer / older
- Julian: What kind of output is needed?
Copy packages over without rebuilding them
- jml isn't sure if this is a thing
  - james_w: it is, may want a policy on the archive to say whether rebuilds are default or not.
  - Julian: I think every quirk should be policy-based.
Support different release cycles and release models from the parent distro
- OEM case is frequently a small, finite number of rolling releases
Translations
merge-o-matic type functionality
- Julian: should be easy using the existing API for syncSources()
Automatic, configurable propagation rules for packages.
Configurable constraints like preventing someone from uploading a package with the same version as a package in a parent distribution (binaries will have conflicting checksums) or uploading a package with an incorrect version (ex. a version that will most likely be higher then the next upload in a parent distribution; ie. version scheme constraints).
- Julian: This sounds like a quirks policy again

What are the workflows for this feature?

Create a distribution
Enter additional data about the relationships between the new distribution and other distributions AND/OR launchpad automatically detects those relationships via the ancestry of the packages in the distribution's archives.

How will we know when we are done?

From https://wiki.ubuntu.com/Specs/M/ARMArchiveBranching: There will be a number of milestone testcases that we have:

Having basic archive management working and able to accept uploads.
Ability to branch a subset of Ubuntu in to the new archive management software.
Ability to view differences between Ubuntu and a derivative using the web interface.
Ability to do the same via the API.
Ability to trigger syncs using the web interface.
Ability to do the same via the API.

How will we measure how well we have done?

Creating a new derived distroseries:

New portlet for the distroseries page:

Showing packages differences:

Check over the Ubuntu owner / bug supervisor etc model and see if it's relevant to non-standard projects
Look up past literature on this subject
Image building suddenly becomes way more interesting with this
- A distribution that's just customization practically demands to be played with
- Cody: Launchpad should focus on improving existing services before jumping into image building. External services and tools can be used in the mean time.
What Ubuntu-specific scripts are we running against Launchpad
Is this a for-pay service?
Derivative distributions should be first class distributions.
A derivative distribution can be a distribution derived from a derived distribution and so on.
Configurable, entirely flexible, powerful policies about behaviors are key.
- Julian: Huge +1