launchpad development|
Size: 4393
Comment:
|
Size: 4650
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 2: | Line 2: |
XXX - more text here |
|
| Line 9: | Line 7: |
| '''As a ''' Linaro partner<<BR>> '''I want ''' to create a new distribution/archive in the hosting software in 3 or 4 clicks<<BR>> '''so that ''' this does not require deploying a new instance for each distribution.<<BR>> '''As a ''' Linaro partner<<BR>> '''I want ''' this new distribution visible only to a certain set of people, and only a subset of that group can upload<<BR>> '''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'''<<BR>> '''I want''' upload modified packages to an archive for a hardware project<<BR>> '''so that''' others who are working on the project can then build on top of this work.<<BR>> '''As Lou,''' the lead developer on the project<<BR>> '''I want''' to go to a web page and see the current state of the archive<<BR>> '''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.<<BR>> |
|
| Line 11: | Line 25: |
| ''Why are we doing this now?'' | We are doing this so it's easier for Linaro partners and Canonical's OEM team to build custom distributions. |
| Line 13: | Line 27: |
| ''What value does this give our users? Which users?'' | 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. |
| Line 17: | Line 31: |
| * Kiko Reis | * Linaro |
| Line 19: | Line 33: |
| * cody * smagoun * ??? |
|
| Line 27: | Line 38: |
| * Ability to sync packages, some auto, some manual | * Ability to sync packages from the parent series, some auto, some manual, optionally rebuilding them * merge-o-matic type functionality, see merges.ubuntu.com |
| Line 38: | Line 50: |
| * 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). |
|
| Line 43: | Line 59: |
''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 |
|
| Line 71: | Line 61: |
| ''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. |
(see use cases above) |
| Line 92: | Line 79: |
| == Mockups == Creating a new derived distroseries: {{attachment:new-derivied-distroseries-mockup.png}} New portlet for the distroseries page: {{attachment:derived-portlet-mockup.png}} Showing packages differences: {{attachment:derived-series-diffs.png}} {{attachment:derived-series-missing-packages.png}} {{attachment:derived-series-unique-packages.png}} |
|
| Line 96: | Line 95: |
| * 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. |
|
| Line 100: | Line 96: |
| * Is this a for-pay service? | |
| Line 102: | Line 97: |
| * A derivative distribution can be a distribution derived from a derived distribution and so on. | |
| Line 104: | Line 98: |
| * Julian: Huge +1 |
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
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.
What MUST the new behaviour provide? Nice to have:
(see use cases above)
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: How will we measure how well we have done?
Creating a new derived distroseries: New portlet for the distroseries page: Showing packages differences:
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
Stakeholders
Constraints
Workflows
Success
Mockups
Thoughts?
