LEP/DerivativeDistributions

Not logged in - Log In / Register

Revision 12 as of 2010-07-15 13:42:19

Clear message

Derivative Distributions

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

As a Linaro partner
I want to create a new distribution/archive in the hosting software in 3 or 4 clicks
so that this does not require deploying a new instance for each distribution.

As a Linaro partner
I want this new distribution visible only to a certain set of people, and only a subset of that group can upload
so that it's easy to see who is in each of those groups on a single page, at most 1 click from the overview page of the distribution. It is also simple to modify each of the groups, with at most 3 clicks required to add or remove someone from one of the groups.

As Meg who works for a partner enabling pre-release hardware
I want upload modified packages to an archive for a hardware project
so that others who are working on the project can then build on top of this work.

As Lou, the lead developer on the project
I want to go to a web page and see the current state of the archive
so that I am able to remove some obsolete packages. This can be done from a single page, and is at most three clicks to remove a package. Bulk operation should be possible.

Rationale

We are doing this so it's easier for Linaro partners and Canonical's OEM team to build custom distributions.

This brings Launchpad's famous usability and feature set to more people who want to use it but currently have to use 3rd party products to do this.

Stakeholders

  • Linaro
  • OEM Services

Constraints

What MUST the new behaviour provide?

  • Ability to sync packages from the parent series, some auto, some manual, optionally rebuilding them
    • merge-o-matic type functionality, see merges.ubuntu.com
  • 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?
  • arbitrarily-named suites
  • Support different release cycles and release models from the parent distro
    • OEM case is frequently a small, finite number of rolling releases
  • 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).

Nice to have:

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

Workflows

(see use cases above)

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-derivied-distroseries-mockup.png

New portlet for the distroseries page: derived-portlet-mockup.png

Showing packages differences: derived-series-diffs.png derived-series-missing-packages.png derived-series-unique-packages.png

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.