UDSBrussels
|
Size: 7410
Comment:
|
Size: 5201
Comment:
|
| 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
smoother boot splash via grub2 and a boot framebuffer (ColinWatson, ScottJamesRemnant)
Package Culling - find and aggressively deal with packages whose merges have been lagging for several releases
Refactor update-notifier - make update-notifier a more modular design (probably with vala), it has out-grown to be a update-notifier since some time (MichaelVogt)
Remove Demoted Packages on Upgrade - We need to explore the removal of demoted packages on upgrade (all, only auto-installed ones, only default installed ones, only unused... how to detect).
D-Bus Refactor of release-upgrader - discuss refactoring the release-upgrader backend as a dbus service to improve reliability/responsiveness (MichaelVogt)
btrfs Support (seconded by OEM)
CD build speed - CD build speed has been creeping back up of late; attack it again
Discuss testing (seconded by OEM)
10.04 Review - hold this early to aid breakout topics, maybe in the first roundtable
Spring Clean - right after an LTS release is a good time for an aggressive cleanup of things we don't need or that should be extensively refactored
Automated transition testing framework (build, run upstream unit test, 2to3, report on ftbfs and test failures, against any/every python version) (BarryWarsaw)
Eliminate symlinks for python-[central (BarryWarsaw). This is a duplicate of foundations-lucid-robust-python-packaging.
Python 2.7 (BarryWarsaw) That should be tested before UDS as a basis for a decision.
Freezing (e.g. cx_freeze) critical dist upgrade tools? (BarryWarsaw)
Compile for i686 as the default on i386 - instead of i486
Toolchain decisions for Maverick. May be followed up with architecture specific sessions. (MatthiasKlose)
Use Energy Star compliance power settings by default (proposed by OEM)
Use xz compression by default for binary packages (proposed by community member)
Use Swap Files Instead of Swap Partitions (carried over from Karmic)
Better archive crawler (carried over from Lucid)
Finish Upstart (seconded by OEM indirectly for their interest in continued boot performance improvements)
Improved Platform-Internationalization Collaboration (seconded by OEM)
OEM
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
TBD
Declined Sessions
TBD
FoundationsTeam/Maverick/Planning/UDSBrussels (last edited 2010-05-12 12:41:17 by 217)