launchpad development|
Size: 3045
Comment:
|
Size: 3295
Comment: some comments
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 38: | Line 38: |
| * Julian: What kind of output is needed? | |
| Line 41: | Line 42: |
| * Julian: I think every quirk should be policy-based. | |
| Line 45: | Line 47: |
| * Julian: should be easy using the existing API for syncSources() | |
| Line 47: | Line 50: |
| * Julian: This sounds like a quirks policy again | |
| Line 77: | Line 81: |
| * Julian: Huge +1 |
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
- 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.
- 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
- 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
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.
- 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.
- Julian: Huge +1
