Summary

Provide additional functionality and polish to oem-config. Keep oem-config in sync with changes in ubiquity by merging the two projects into a single source tree.

Release Note

A number of changes have gone into oem-config to make it more flexible for OEMs looking to deploy Ubuntu.

Rationale

OEMs and OEM engineers have expressed a desire for a number of specific changes to be make to oem-config, to bring it more in line with their needs.

User stories

Assumptions

Design

Implementation

Merge ubiquity and oem-config

ubiquity and oem-config are similar in structure and function, but are not built from the same source. This has created a number of problems in the past as copy and pasting code shared between the two projects is often forgotten. For this reason, the two projects should be merged and built as separate packages from the same source tree, or alternatively built as a single application that changes functionality based on a command line parameter.

Care should be taken to preserve history. This can also serve as an opportunity to clean up some of the cruft that has accumulated in the structure of both projects as they've evolved.

If this portion of the specification is not completed in time, recent changes to ubiquity should be carried over, such as a newer version of the timezone map and the keyboard selection UI.

Implementation: Done. The work was tracked in the branch lp:~mterry/ubiquity/oem-config-merge

Timezone selection

Network setup

Extra language pack removal

https://bugs.edge.launchpad.net/ubuntu/+source/oem-config/+bug/315644

Some OEMs preseed all of the language packs to be installed, but the user only ends up using one set, which leads to lots of unnecessary updates for the user. It was suggested that an interface to choose which language packs to keep and which to remove be added to oem-config, but doing this strikes me as dumping the problem created by how we deal with language selection and language packs on the user, who likely doesn't want to be bothered with this kind of question. This should be investigated further and automatically removing unneeded language packs or moving the functionality into computer-janitor be considered as alternative options.

Ability to add pages

It should be easy for OEMs to add pages to oem-config using a component that either does not require a backend (asking questions for itself) or a component that automatically picks up and handles confmodules. Either one will feed information to the frontend in a stanardized form it can use to construct an interface.

It should also be made easy to add translateable EULA pages, either by dropping them in a known location on the filesystem, or by a pointing a special EULA oem-config component at them.

Implementation: Done. The work was tracked in the branch lp:~mterry/ubiquity/plugins.

Test/Demo Plan

Test cases already exist for oem-config and ubiquity as part of the CD testing procedures.

Unresolved issues

UDS Lucid Notes

OEM Config Improvements Suggested by OEMs or OEM Services Engineers

What Got Done Last Cycle

What Did Not Get Done Last Cycle


CategorySpec

FoundationsTeam/Specs/KarmicOEMConfigImprovements (last edited 2009-11-19 17:07:32 by 63)