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?

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
• 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.
• 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
• 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).

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?

One possible measure: when we can build Debian on Launchpad the way we build Ubuntu.

Another POV: When Ubuntu can become a derivative of Debian in launchpad.

How will we measure how well we have done?

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
• 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.