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?

Stakeholders

• Kiko Reis
• OEM Services
  • cody
  • smagoun
• ???

Constraints

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:

• new packagesets for derived distros based on parent's packagesets
• diff of packagesets

What MUST it not do?

Subfeatures

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

Workflows

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.

Success

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?

Mockups

Creating a new derived distroseries:

New portlet for the distroseries page:

Showing packages differences:

Thoughts?

• 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
• What Ubuntu-specific scripts are we running against Launchpad
• Derivative distributions should be first class distributions.
• Configurable, entirely flexible, powerful policies about behaviors are key.
  • Julian: Huge +1