Differences between revisions 5 and 6
Revision 5 as of 2010-05-03 10:55:33
Size: 7410
Editor: eth0
Revision 6 as of 2010-05-03 11:07:55
Size: 5201
Editor: eth0
Deletions are marked like this. Additions are marked like this.
Line 19: Line 19:
 * [[UbuntuSpec:foundations-m-upgrade-and-install-testing|Discuss testing]]  * [[UbuntuSpec:foundations-m-upgrade-and-install-testing|Discuss testing]] (seconded by OEM)
Line 34: Line 34:
 * [[UbuntuSpec:foundations-m-go-green| Use Energy Star compliance power settings by default]] (proposed by OEM; seconded by OEM)  * [[UbuntuSpec:foundations-m-go-green| Use Energy Star compliance power settings by default]] (proposed by OEM)
Line 39: Line 39:
 * [[UbuntuSpec:foundations-m-improved-i18n-collaboration|Improved Platform-Internationalization Collaboration]] (seconded by OEM)
Line 45: Line 46:

==== Internationalization ====

 * Collaborate with i18n upstream more closely, especially on release schedule, e.g., we missed ibus-1.3 for LTS 10.04 (High) - general platform issue; Foundations will host a UDS discussion for this
 * Per-language ISOs (e.g. a Chinese ISO, a Swahili ISO, etc) (Low) - Foundations can't support this as a whole -- it would explode our test cases; however, Foundations will work with OEM if they need help generating their own ISOs

==== Small Disk Configuration Support ====

 * Audit packages and see if "depends" can become "recommends", making it easier for OEM to reduce dependency lists. (High) - let's use the bug-filing process to accomplish this: OEM can file, and Foundations can address this on a case-by-case basis
   Example: xserver-xorg depends on xserver-xorg-video-all (actually, it depends on this OR a single driver) which pulls in *all* video drivers; if it were only recommended, you could specify only xserver-xorg-video-intel e.g. for your image
 * Remove all on-disk help/documentation and move it online. At the very least, split documentation into separate foopackage-doc.deb and make it a recommends. (High) - this is not appropriate for all use cases; we need to address this on a case-by-case basis; doing for all would guarantee that the index files would explode in size
 * Compressed r/w filesystem (High) - we will get this via btrfs
   * If btrfs is not feasible for some reason, we need a 'blessed' (by distro) r/w filesystem that supports compression (reiser, something FUSE-based, something else?)
   * We need r/w support to prevent the problem of updates taking too much disk space when using a r/o compressed filesystem like squashfs+unionfs
 * Updates for small disks - perform update as a sequence of partial atomic steps to minimize the use of disk (Med) - we do this now... so Foundations needs more detail to understand what need is not being fulfilled; OEM may mean downloading chunks and then applying it?

==== Other ====

 * BIOS validation tool (kernel team problem, not foundations? Colin King already working on this?) (High) - mostly Kernel with some Foundations
 * More stress testing before release (Med) - we will create UDS session for this: improving our testing procedures, using more automated tests, further brainstorming, etc.

Note: This page is for prioritizing Foundations track UDS-M sessions. For general Maverick planning, please see FoundationsTeam/Maverick/Planning.

Proposed Specs


Usability and Performance

  • Hybrid suspend/hibernate by default. Allows the system to go to sleep, but also stores a hibernate image on disk. If the battery dies, the system wakes from the hibernate image (Med) - this might be ideal... however, not sure how feasible it will be; would make suspend a lot slower; means we'd be forced to use dodgey kernel hibernate code

Accepted Sessions


Declined Sessions


FoundationsTeam/Maverick/Planning/UDSBrussels (last edited 2010-05-12 12:41:17 by 217)