KarmicOEMConfigImprovements
|
Size: 7169
Comment:
|
Size: 5311
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 4: | Line 4: |
| * '''Created''': * '''Contributors''': * '''Packages affected''': |
* '''Created''': 2009/06/11 * '''Contributors''': EvanDandrea * '''Packages affected''': oem-config, ubiquity |
| Line 10: | Line 10: |
| This should provide an overview of the issue/functionality/change proposed here. Focus here on what will actually be DONE, summarising that so that other people don't have to read the whole spec. See also CategorySpec for examples. | 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. |
| Line 14: | Line 14: |
| This section should include a paragraph describing the end-user impact of this change. It is meant to be included in the release notes of the first release in which it is implemented. (Not all of these will actually be included in the release notes, at the release manager's discretion; but writing them is a useful exercise.) It is mandatory. |
A number of changes have gone into oem-config to make it more flexible for OEMs looking to deploy Ubuntu. |
| Line 20: | Line 18: |
| This should cover the _why_: why is this change being proposed, what justifies it, where we see this justified. | 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. |
| Line 23: | Line 21: |
* Bob's graphics card will not work properly until after oem-config has been run. * Mario would like to provide a EULA for software his company is distributing with their Ubuntu image. * Dave is confused as to why he has a number of language pack updates to install for languages he does not speak. |
|
| Line 28: | Line 30: |
| You can have subsections that better describe specific parts of the issue. |
|
| Line 32: | Line 32: |
| This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like: | * Investigate falling back to bulletproof-X or failing that, the console-based oem-config when X fails. * Add success and failure preseedable commands to oem-config, to match the ones in ubiquity. |
| Line 34: | Line 35: |
| === UI Changes === | === Merge ubiquity and oem-config === |
| Line 36: | Line 37: |
| Should cover changes required to the UI, or specific UI that is required to implement this | 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. |
| Line 38: | Line 39: |
| === Code Changes === | 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. |
| Line 40: | Line 41: |
| Code changes should include an overview of what needs to change, and in some cases even the specific details. | 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. |
| Line 42: | Line 43: |
| === Migration === | '''Implementation:''' Done. The work was tracked in the branch [[https://code.launchpad.net/~mterry/ubiquity/oem-config-merge|lp:~mterry/ubiquity/oem-config-merge]] |
| Line 44: | Line 45: |
| Include: * data migration, if any * redirects from old URLs to new ones, if any * how users will be pointed to the new way of doing things, if necessary. |
=== Timezone selection === * Provide translated timezones in the drop down lists. ('''implementation:''' Done. This work was tracked in the branch [[https://code.launchpad.net/~mterry/ubiquity/translated-timezones|lp:~mterry/ubiquity/translated-timezones]]) * Add country information to the timezone selection logic, so that when someone clicks south of Austin, TX they do not end up with a Mexican city selection. This will involve adding multiple colors to the color coded map for the same timezone, and modifying the timezone code to account for the change. * Add Geo``IP support (already being worked on by cjwatson) to make a better default timezone selection. === Network setup === * Copy Network Manager portion of the keyring to the target system at install. * Look into embedding network-manager-netbook or some other NetworkManager frontend in the interface when running in only-ubiquity mode or when in oem-config. === 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:''' The work is tracked in the branch [[https://code.launchpad.net/~mterry/ubiquity/plugins|lp:~mterry/ubiquity/plugins]] and has its own [[Ubiquity/Plugins|wiki page]]. |
| Line 51: | Line 72: |
| It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage. This need not be added or completed until the specification is nearing beta. |
Test cases already exist for oem-config and ubiquity as part of the CD testing procedures. |
| Line 57: | Line 76: |
| This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved. | * Investigate whether it's now possible to create a user with non-latin characters in the username. * [[mterry]] - No, I don't think so. According to [[http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html|IEEE Std 1003.1-2004]], usernames should only be `[a-zA-Z0-9._][a-zA-Z0-9._-]*`. |
| Line 61: | Line 81: |
| {{{ Address three issues raised by the Canonical OEM Services team: 1. Better time zone selection (less twitchy, translated cities, less crazy drop down (100s of items), not necessarily clear which city to pick). Debconf has support for a translated list (local names) of timezones per country, but we don't use it because country + timezone are picked at the same time. * ubiquity and oem-config are similar but the codebases have diverged * changes don't always get merged back in * timezone selection has been fixed in ubiquity and need to be migrated to oem-config * mterry : merging oem-config and ubiquity - focus effort on single code base and if possible a single package implementation * don't intuitively know which 'city' to choose (use case: I am in Austin, TX and don't realize Chicago is my timezone city) also, set the correct default time server correctly (potential bug) * when selecting the nearest city in a timezone, stay whithin the country? (Use case: I click near Austin, TX but a city in mexico gets selected instead of Chicago) * make it more clear that the timezone map can be clicked on by timezone * potentially zoom on the timezone map near the cursor (Use case: some places the cities are too close together) - when zooming, show the cities on the map instead of just the map on the zoomed back view * translate city names http://people.ubuntu.com/~evand/tmp/new_timezone_nyc.png GEOIP coming, RT ticket Translated timezones, can do. 2. Keyboard selection is confusing for non-technical users. Can we possibly do this automatically or provide a smaller list to make it less overwhelming (restricted to country the user chose)? User isn't sure how many keys they have or if they have dead keys ("none of mine are broken"). * again in ubiquity but not yet carried over * often we setup a default layout but also install another keyboard layout for the user to switch to after install - some method of displaying the actual keyboard layout they have already selected (think picture of keyboard) - more usability testing with the keyboard selection - possibly use a 'calculate layout' option (from alternate installer) * localization support * usernames are limited to latin characters * hovering text in native language c http://developer.amazonwebservices.com/connect/entry.jspa?externalID=609 Could do keyboard detection by a few key presses, but we have limited resources and that's a lot of work. 3. Setup wifi, so it's ready to go on first user experience, and we can download language packs. * Don't have network manager running because it is not a full gnome session * how do you carry the setup over to the user session or save to their settings * put the configuration into the installed system (for ubiquity) for the user Network Manager Netbook: http://www.gnome.org/~michael/blog/2009-05-21.html 4. username limit to latin chars * covered above 5. Fallback to -debconf config if X fails (https://bugs.edge.launchpad.net/ubuntu/+source/oem-config/+bug/315647) * Use case: user boots to the system, but it doesn't boot into X - fall back to a usable debconf instead of nothing * will fall back to bullet-proof X after they setup their user - what about falling back to bullet-proof X for the user setup? and never drop the user back into a console 6. Purge unneeded language packs (https://bugs.edge.launchpad.net/ubuntu/+source/oem-config/+bug/315644) * Use case: we preinstall all language packs, when the user installs the system, they still have tons of unused languages installed and now need to update them which takes longer than nessesary - solvable by network connectivity and downloading just the one you need? what about no network - if you are not on the dvd and use the cd you download the needed language pack * choose which language packs to keep and which ones (all the others) to purge after the oem-config process - prevent unnessesary package updates - computer janitor? - language selector? * at least the default language needs to be there, other languages could be done later 7. Add support to show EULAs for third party packages * EULA text is also localized * potentially a EULA viewing page object that can show EULAs 8. Simplify mechanism to add pages to wizard 9. hooks to run scripts after oem-config completes (system hooks, user hooks) * Ubiquity does this, so should oem-config * add to debconf template * we have scripts that need dpkg and oem-config has a lock on it * useful to have a script for the first time the user logs in - Use case: finding out the translated music directory?, also for branding }}} |
Launchpad Entry: foundations-karmic-oemconfig
Created: 2009/06/11
Contributors: EvanDandrea
Packages affected: oem-config, ubiquity
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
- Bob's graphics card will not work properly until after oem-config has been run.
- Mario would like to provide a EULA for software his company is distributing with their Ubuntu image.
- Dave is confused as to why he has a number of language pack updates to install for languages he does not speak.
Assumptions
Design
Implementation
- Investigate falling back to bulletproof-X or failing that, the console-based oem-config when X fails.
- Add success and failure preseedable commands to oem-config, to match the ones in ubiquity.
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
Provide translated timezones in the drop down lists. (implementation: Done. This work was tracked in the branch lp:~mterry/ubiquity/translated-timezones)
- Add country information to the timezone selection logic, so that when someone clicks south of Austin, TX they do not end up with a Mexican city selection. This will involve adding multiple colors to the color coded map for the same timezone, and modifying the timezone code to account for the change.
Add GeoIP support (already being worked on by cjwatson) to make a better default timezone selection.
Network setup
- Copy Network Manager portion of the keyring to the target system at install.
Look into embedding network-manager-netbook or some other NetworkManager frontend in the interface when running in only-ubiquity mode or when in oem-config.
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: The work is tracked in the branch lp:~mterry/ubiquity/plugins and has its own wiki page.
Test/Demo Plan
Test cases already exist for oem-config and ubiquity as part of the CD testing procedures.
Unresolved issues
- Investigate whether it's now possible to create a user with non-latin characters in the username.
mterry - No, I don't think so. According to IEEE Std 1003.1-2004, usernames should only be [a-zA-Z0-9._][a-zA-Z0-9._-]*.
BoF agenda and discussion
FoundationsTeam/Specs/KarmicOEMConfigImprovements (last edited 2009-11-19 17:07:32 by 63)