• Immutable Page
• Info
• Attachments
• More Actions: Raw Text Print View Render as Docbook Delete Cache ------------------------ Check Spelling Like Pages Local Site Map ------------------------ Rename Page Delete Page ------------------------ Subscribe User ------------------------ Remove Spam Revert to this revision Package Pages Sync Pages ------------------------ Load Save SlideShow

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 to 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

• Ability to sync packages from the parent series, some auto, some manual, optionally rebuilding them
  • merge-o-matic type functionality, see merges.ubuntu.com
• Allow one distribution to have many derived distributions
  • These derived distributions must be discoverable from the "parent" distribution.
• Track state of packages compared those in the parent's archive:
  • 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
    • User-defined periodic auto-sync of explicitly listed packages from parent
• Package branches for derived archives/distros
  • XXX - do we maintain official package branches in Launchpad or are they the responsibility of the derived distro "owner"? - jml
• Create a new distribution
  • Only XXX admins (commercial admins right now but this should change) can make new distributions, however the "driver" of the new distribution will be allowed to create/derive new series
• Create new derived distro series based on packagesets
  • Restricted to distro drivers
  • Required because people don't want to import all of parent (think about build time)
• Support different release cycles and release models from the parent distro
  • OEM case is frequently a small, finite number of rolling releases
• Open distroseries well before the series is ready for uploading so that QA folk can assign bugs to future distroseries

Nice to have

• new packagesets for derived distros based on parent's packagesets
• diff of packagesets
• Arbitrarily-named suites

  • XXX - how are these created? who has permission to do so? how do they interact with bug affects & package branches? - jml

• 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)
  • uploading a package with an incorrect version (e.g. a version that will most likely be higher then the next upload in a parent distribution; ie. version scheme constraints).
  • XXX - "like"? Please list the configurable constraints we're providing.
  • XXX - What are the motivations for these features? - jml

Workflows

• Linaro partner creates a new distribution and derives a new series from an Ubuntu series.

• After a couple of weeks of hacking on a derived distribution, Meg syncs all the changes from Ubuntu into her derived series.

• Lou proposes a branch from his derived distribution to be merged into the upstream distribution

• Kiko looks at the Linaro distribution (derived from Ubuntu), gets a visual sense of the size of the delta between Ubuntu & Linaro. He investigates further, and sees that there are only one or two packages that are significantly different. He requests a merge of the Linaro packages to the upstream.

• Meg figures out that a bug in her derived distribution is actually a bug in the parent distribution. She files a bug and adds a bugtask for the upstream distribution package and a bugtask for her own package.

• Bryce is brought in to consult on an X problem in Linaro. He looks at the Linaro distribution and is able to quickly see the differences between Ubuntu & Linaro for X packageset packages only.

Success

How will we know when we are done?

Bugs are at: Bugs for this LEP

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

• Having basic archive management working and able to accept uploads, build packages and publish them to an archive.
• 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

• How can we communicate the changelog? Mathias had a good idea - make it easy for people to view the changelog without leaving the page. This is hard for a few reasons, but would be great to do in some form. So, as is, users can click on the Lucid package and then there's a link to the full changelog, and in the DB we have the most recent changelog entry.

  • Easiest incremental enhancement here would be to include the latest changelog entry in the alt text for the link... ie. it would only be discovered if someone went for more information (but even then, only if they hold the mouse still).
  • Next incremental enhancement would be a JS only one of adding a (view changelog) link next to the package via JS that displays the changelog in an overlay dialog (ie. without leaving the page).
  • Now that we're using a dropdown, we could display the latest changelog entry of either or both?

Derived series missing packages

• Is the '6 new Lucid packages that have been ignored' link enough? When clicking on this link, all previously ignored packages will be displayed with an extra column for the comment. I'd rather do this than additionally include an extra filter option "include ignored packages" or similar? -- michael.nelson 2010-08-18 08:06:28

Derived series unique packages

• Is there anything else useful for the table? (I've added description)

User testing