launchpad development|
Size: 10274
Comment:
|
Size: 10384
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 83: | Line 83: |
''Bugs are at:''' [[https://launchpad.net/launchpad-project/+bugs?field.tag=derivation|Bugs for this LEP]] |
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
- Report of differences against parent(s)
- 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:
Should we use checkboxes? I personally think that we
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.
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
Is there anything else useful for the table? (I've added description)
Took place as remote audio calls on July 28th and August 2nd 2010, with: Transcripts and audio
I see three main "features" here: Creating distributions that can be uploaded to that will then build & publish packages. Synchronizing distributions and the associated UI & new controls. There's also a bunch of associated stuff that must be considered:
Creating a new derived distroseries: New portlet for the distroseries page: Showing packages differences:
How will we measure how well we have done? Mockups
Creating a new derived distroseries
should consider checkboxes for the architectures... even if there are say 15 different architectures, they can be adequately grouped using fieldsets (eg. one for all arm arches) where appropriate. This would enable people to know what they are selecting from at a glance. My main concerns with a js picker (like the tags one) is that (I imagine) users need to know some letters of the arch to search for. -- michael.nelson 2010-08-17 07:08:27 New portlet for the distroseries page
Showing packages differences
Derived series differences
Derived series missing packages
Derived series unique packages
User testing
Round 1
Recommendations Thoughts?
Old mockups
