launchpad development|
Size: 1893
Comment:
|
Size: 3051
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 33: | Line 33: |
| * File a bug upstream, where upstream is the parent distribution | * Ability to push a bug upstream to a parent distribution |
| Line 41: | Line 41: |
| * Support different release cycles from the parent distro * OEM case is frequently a small, finite number of releases * Translations?!? |
* 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). |
| Line 49: | Line 52: |
| * Create a derivative distribution * ??? |
* 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. |
| Line 58: | Line 60: |
Another POV: When Ubuntu can become a derivative of Debian in launchpad. |
|
| Line 68: | Line 72: |
| * 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 70: | Line 75: |
| * 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. |
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.
- jml isn't sure if this is a thing
- 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.
- A distribution that's just customization practically demands to be
- 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.
