Final

Differences between revisions 19 and 20
Revision 19 as of 2010-11-03 21:32:07
Size: 27832
Editor: 99-156-85-10
Comment: removed 2 stage installer for server...not for natty...but soon!!! :)
Revision 20 as of 2010-11-10 18:16:02
Size: 30564
Editor: port-20669
Comment:
Deletions are marked like this. Additions are marked like this.
Line 63: Line 63:

 * Linaro Multimedia Team investigate options to optimize jpeg decoding transparently on ARM systems that have a NEON unit and hardware support
 * The Online Services team will work on integrating ubuntu one with shotwell
 * Linaro Graphics Team will work on optimizing runtime behaviour on ARM for vector graphic libraries like cairo, skia, but also toolkits like qt by automatically selecting the best backend and using NEON units were possible
 * The Linaro User Platforms team will provide convenience images to support graphics and multimedia development efforts within and outside of linaro.
 * The Linaro Graphics Team will continue its work on improving availability direct rendering support for graphics on the various ARM SoCs
 * The Touch Team will work explore various creative ways to use touch interfaces in ubuntu; among others, this includes connecting the ipad as making a touch app to control your TV from ubuntu
 * Work to improve low latency audio will be conducted to make jack work with pulseaudio.
 * The Linaro Graphics Team will continue to extend the graphics benchmark software and tools available in ubuntu and linaro; among other approaches, trace support along the line of cairo tracke for more toolkits than cairo is being investigated.
 * Depending state of touch screen support the desktop team will stay on xorg 1.9 or move to 1.10
 * The Desktop Team will work on strengthening the use of gallium by default; which hardware will make use of gallium drivers by default is subject to upstream and user feedback
 * The Desktop Team will ensure that xvfb becomes more solid as this is a requirement of the security team
 * The Design Team will continue to investigate how color management in ubuntu can be streamlined
 * Ubuntu will work on improved multi monitor support, especially for unity
 * The Linaro Multimedia Team will work on improving support for ARMs low-power mode when using pulseaudio; this will involve investigating adding smart alsa-sink buffer tuning while still ensuring that real time events will not get delayed
 * The Ubuntu ARM team will make GLES 2.0 the default GL standard used for applications and tookits in the ubuntu archive that support it
 * The Linaro Multimedia Team will work on consolidating the zero copy support for gstreamer and omax
 * The Linaro Multimedia team will further optimize the ffmpeg AAC and VP8 software codecs for ARM such that it leverages NEON and multi-core support available in modern ARM hardware
 * The Linaro Multimedia team will also support its own work as well as the multimedia software and hardware developer community by creating a multimedia test library that can be redistributed under a free software license

Ubuntu Developer Summit Proceedings

Ubuntu The Project

  • The Upstream Contacts project will perform six-monthly surveys to get a finer impression of upstream perspectives on Ubuntu. There will be a continued focus on every project having an Upstream Contact assigned.
  • There was a discussion about the components needed to allow community developers to quickly build new web applications for Ubuntu projects. These come from the common aspects of loco-directory, summit, harvest and awstrial. A project has been formed to build a Django based solution using Bazaar and Launchpad to help community teams provide these resources.
  • Developer advocacy will continue to be a focus in Natty with work going into creating a demo script for explaining how development works, creating screencasts and reviewing our existing documentation.
  • Accessibility was a key focus at this UDS and in support of the plan to build accessibility support into Unity for 11.04, the community Accessibility Team reviewed and improved their on-boarding documentation, and will be providing bug triage and testing resources throughout the Natty cycle. In addition to this, accessibility tests will be appended to the regular release tests and ISO testing.
  • The sponsorship queue in this cycle will get some significant support with a new "Patch Pilot" scheme. The scheme will work by providing Canonical engineering staff throughout the month who will focus on reviewing new contributions made by developers who are working towards being approved Ubuntu developers. This should provide a faster review time and on-ramping of Ubuntu developers.
  • Work will continue in the Translations community and as part of this work an introductory video will be produced to explain how people can get involved in the community, a language packs schedule has been defined, there will be a series of translations training sessions throughout the cycle, and a first iteration of translations.ubuntu.com will be produced.
  • The community made plans to produce a Global Directory, inspired by the LoCo directory, which shows all teams in the Ubuntu community. As part of this work a meeting tracker which integrates with fridge.ubuntu.com has been planned.

  • The Release Team met and agreed to update Process pages to include explicit post mortem discussion in future, clarify roles in the release pages, merge release schedules into a master table, and review the Natty cycle and make changes where appropriate.
  • The Leadership Code Of Conduct was agreed to play a formal role in leadership in Ubuntu, and the translations community will be porting it to DocBook so it can be translated by the community.

Application Developers

  • The Ubuntu One team will be delivering an application developer API that application authors can use to build Ubuntu One support into their apps. Core focus for this API will be desktop + web + mobile.
  • Natty will see significant work in the area of gestures. A high-level gesture language will continue to be developed, with support in GTK/Qt apps. The GEIS 2.0 gesture language resulted from experience with GEIS 1.0, and it addresses awkward aspects of usage so far.
  • The Ubuntu Developers' Manual team will organize a sprint or other focused period of time to produce the manual, perhaps hiring a technical writer or editor as a consultant.
  • The decision was taken to deliver apps form extras.ubuntu.com into /opt, and under an new namespace in order to avoid present and future naming collisions. This will require work on the Python build system to support byte compiling in /opt, as well as to solve other issues.
  • Long term support for full application sandboxing was also discussed. It was determined that sandboxing will be a multi-release effort, and will not appear in Natty.
  • The Quickly ubuntu-application template will be enhanced to make the user edited code cleaner, and to make it easier to access widgets and signals from code.
  • Game development was discussed, but will not receive any significant focus outside the existing Quickly PyGame template. A lack of artwork was identified as a blocking issue, but no one committed to creating a repository of free game art.

  • The Quickly Widgets project will not receive any significant focus, and will remain a community driven project.

Read further notes from this track at http://wiki.ubuntu.com/UDSProceedings/N/ApplicationDevelopers

Package Selection and System Defaults

  • Unity will provide the default desktop experience for Ubuntu Desktop

  • Gnome 3.0, including Gnome Shell, will be included in this release.
  • Software Center will have two major feature updates. These updates will allow Ubuntu users to:

    1. donate money directly to providers of free software in the Ubuntu Software Center
    2. access and provide ratings, plus reviews, for all software in the Ubuntu Software Center
  • In accordance with the Ubuntu Promise, Unity will be made accessible with a focus on the launcher, the panel, and the indicators that go with it.

  • We will target Banshee as the default music player.

  • The boot experience for Ubuntu Server will be improved through better integration with upstart and plymouth.

  • In our on-going effort to support community-driven open source server related projects, the Ubuntu Server team will ensure the integration of Drizzle, a "Lightweight SQL Database for Cloud and Web".

  • There will be further focus on automation of server and cloud image testing as a result of successful automation of ISO testing during the Maverick cycle using Hudson, which will also be packaged in this cycle.

  • The Ubuntu Server team will also package Tomcat 7 and work with OW2/JOnAS to evaluate packaging of a full Java Enterprise Edition (EE) stack.

  • In Ubuntu 11.04, we will re-assess our networking stack from the kernel up to the user interface layer, with a singular goal of giving the best network experience to Ubuntu users to date.
  • Natty development will open with gcc-4.5 as the default toolchain, with an aggressive goal of shipping gcc-4.6 by release.
  • Linaro will create a new ARM-targeted "developer" image. This image will be a strict superset of the currently produced headless image, to reduce maintenance, and will include developer tools and other useful packages generally interesting/useful to ARM developers.

Read further notes from this track at http://wiki.ubuntu.com/UDSProceedings/N/PackageSelectionAndSystemDefaults

Cloud Infrastructure

  • For Ubuntu 11.04, we will continue to support and integrate key cloud infrastructure features delivered by Eucalyptus.

  • We will look at providing an installation service for physical cloud node deployments that will automatically install, configure, and integrate the new node into an existing Ubuntu-based cloud infrastructure.
  • We will make numerous improvements to the Ubuntu Cloud images, that include expanding support for use on Cluster Compute Images on Amazon EC2 and added support for Rightscale in cloudinit.

  • In Natty, we will tighten our integration with Puppet by:

    • allowing a new system, installed by the Ubuntu's cloud installation service, to automatically register itself with the puppet service, so that it can be configured as the expected cloud component.
    • packaging mcollective to get a scalable distributed command infrastructure (e.g. trigger puppet runs).
    • writing puppet modules to configure Ubuntu-based cloud components
  • The Ubuntu Server team will improve the integration of both Openstack and Hadoop, as well as package Open vSwitch and zeromq.

  • In Ubuntu Server 11.04, we will look to provide support for Linux Containers in Ubuntu-based cloud deployments by helping to make LXC ready for production.

  • Our cloud image store is one of the key differentiators that Ubuntu offers. During the Natty cycle, we will attempt to meet the needs of our users, with a focus on Enterprise deployments, ISVs, and ISPs.

Read further notes from this track at http://wiki.ubuntu.com/UDSProceedings/N/CloudInfrastructure

Multimedia

  • Linaro Multimedia Team investigate options to optimize jpeg decoding transparently on ARM systems that have a NEON unit and hardware support
  • The Online Services team will work on integrating ubuntu one with shotwell
  • Linaro Graphics Team will work on optimizing runtime behaviour on ARM for vector graphic libraries like cairo, skia, but also toolkits like qt by automatically selecting the best backend and using NEON units were possible
  • The Linaro User Platforms team will provide convenience images to support graphics and multimedia development efforts within and outside of linaro.
  • The Linaro Graphics Team will continue its work on improving availability direct rendering support for graphics on the various ARM SoCs

  • The Touch Team will work explore various creative ways to use touch interfaces in ubuntu; among others, this includes connecting the ipad as making a touch app to control your TV from ubuntu
  • Work to improve low latency audio will be conducted to make jack work with pulseaudio.
  • The Linaro Graphics Team will continue to extend the graphics benchmark software and tools available in ubuntu and linaro; among other approaches, trace support along the line of cairo tracke for more toolkits than cairo is being investigated.
  • Depending state of touch screen support the desktop team will stay on xorg 1.9 or move to 1.10
  • The Desktop Team will work on strengthening the use of gallium by default; which hardware will make use of gallium drivers by default is subject to upstream and user feedback
  • The Desktop Team will ensure that xvfb becomes more solid as this is a requirement of the security team
  • The Design Team will continue to investigate how color management in ubuntu can be streamlined
  • Ubuntu will work on improved multi monitor support, especially for unity
  • The Linaro Multimedia Team will work on improving support for ARMs low-power mode when using pulseaudio; this will involve investigating adding smart alsa-sink buffer tuning while still ensuring that real time events will not get delayed
  • The Ubuntu ARM team will make GLES 2.0 the default GL standard used for applications and tookits in the ubuntu archive that support it
  • The Linaro Multimedia Team will work on consolidating the zero copy support for gstreamer and omax
  • The Linaro Multimedia team will further optimize the ffmpeg AAC and VP8 software codecs for ARM such that it leverages NEON and multi-core support available in modern ARM hardware
  • The Linaro Multimedia team will also support its own work as well as the multimedia software and hardware developer community by creating a multimedia test library that can be redistributed under a free software license

Read further notes from this track at http://wiki.ubuntu.com/UDSProceedings/N/Multimedia

Performance

Desktopcouch speed and performance

  • Slim down packages (ad-hoc couch-specific erlang build conflicting, libjs without xulrunner).
  • Lightweight system-level proxy that handles deferred starting of couch, and multiplexing to individual per-user couches.
  • Auto-compaction (opt-out).
  • Investigate erlang's ability to have erlang processes limit cpu/memory use; tracemonkey (tracing), updated json serializer

NEON/Vectorizer Direction

  • Work on multiple sizes first, then special loads and stores
  • Investigate benchmarks and what could be vectorised, e.g. widening multiply (short[n] * short[n] -> int[n])

Performance inside GCC

  • Continue with the current investigate/implement/repeat cycle
  • Start measuring performance with CI and check for regressions

Improve boot-time performance on ARM, from power-on to user-space

  • Unless you use lvm, cryptsetup, or raid, the kernel has all the information to be able to resolve an (fstype,uuid) pair itself! Fix the kernel to do this so we don't need to use initramfs at all
  • Reduce the default timeout on u-boot to something less than 10 seconds

Performance improvement areas outside GCC

  • Get GOLD on ARM up and running
  • Add IFUNC support as the best way of handling A8/A9/NEON variants

Kernel Storage Performance

  • SD and eMMC: Add support for background operations to drivers and to filesystems. Add support for reliable write. Investigate adding support for high priority interrupt.
  • Add "trim" support to SD. Add to SD standard, implement in drivers, and appropriate filesystems.
  • SD: Investigate eMMC (version 4.4 standard) "trim" support in Linux kernel and ARM SoC. Fill out implementation and fix bugs as needed.

Improve Memory Footprint for ARM

  • Sample kernel memory usage as well as userspace
  • Compare x86<->ARM (helpful to flag up arch-specific regressions)

  • Discuss with the Ubuntu packaging folks about the footprint of update-manager, apt-xapian-index
  • Define and sample some particular app use cases (web browser, media playback etc.)
  • Follow up on the status of work on link-time dead code elimination, and hot/cold data partitioning and prelinking
  • Analyse X resource consumption

Reducing Installation/CD Footprint

  • Remove changelogs.Debian.gz (after a final legal check) [11 MB]
  • Optimized PNGs and SVGs [12.5 MB]
  • Remove perl and perl-modules (keep perl-base) [8 MB]
  • Remove DRI MESA drivers for old cards, add Jockey handler [12 MB]
  • If necessary, drop Evolution contacts sync from default install, which will drop couchdb/erlang
  • Install footprint optimizations which don't affect CD size: compressed apt indexes, remove apt source package cache, remove rsyslog redundancy

Kernel Memory Regions

  • Calculations showed 15% battery-lifetime extension from DRAM power-off use case.
  • Additional use cases identified: having drivers announce contiguous memory-needs during boot, changing memory-region attributes at run time in order to compact non-movable memory.
  • Paul to communicate use cases to IBMer working this to see if they can be accommodated.

Read further notes from this track at http://wiki.ubuntu.com/UDSProceedings/N/Performance

Hardware Compatibility

  • Handling unusual input devices with aplomb
    • [JFo] (hold off for now) CFT to get a poll of unique/unusual buttons and interesting form factors
    • Review/Update Hotkeys and Hotkeys/Troubleshooting wiki page
    • Find some data examples and speak with Keng-Yu (acelan) for the small bits of scripts to parse data
  • Handling the hardware X can't properly autodetect
    • [apw] investigate whether the EDID etc could become writable at the kernel level:TODO
    • [apw] can we move i915 power etc configs to sysfs:TODO
    • [raof] investigate extending the gnome-monitors-applet to add extra randr modes:TODO
    • [bryceharrington] to find summary of quirks and publish with spec
    • [jk-ozlabs] proposal for device tree node specifying the graphics quirks
  • Kernel Configuration
    • [jj] investigate CONFIG_INTEL_IDLE and verify if we want this inconsistent on virtual
    • [apw] Add CONFIG_IMA to enforcer
    • [jj] XEN_PCI_PLATFORMDEV (sp?) turned on for all, but test first
    • [apw] CONFIG_IPV6 - add to enforcer
    • [apw] fix up above CONFIG options per notes
    • [apw] investigate building in CONFIG_AGP drivers (only 4)
    • [cking] investigate setting CONFIG_HZ=1000, allows X to run faster
  • Kernel Bug Handling
    • [jeremyfoshee] to develop process for handling, validation & closure, and document in the wiki

    • [jeremyfoshee] produce summary report with the priority bugs from each stakeholder
    • [jeremyfoshee] to drive existing bugs with patches list to zero and keep it there
    • [jeremyfoshee] look at kerneloops reports to better detect duplicates
    • [jeremyfoshee] look at documentation for kernel testing (installation etc), test and update
    • [bdmurray] work with QA and community to dog food wiki docs
    • [kamal] to clean up / merge kernel wiki docs about how to change a grub entry: "Kernel boot params for newbies"
    • [pgraner] schedule a stackexchange meeting with Jorge to see how stackexchange can help with triage/QA
    • [jeremyfoshee] look at primary arsenal message for applicability to flavour (not appropriate for arm)
    • [jeremyfoshee] update apport-hooks verbage
    • [jeremyfoshee] look at arsenal flow and document
    • [canonical-kernel-team] ensure we have documentation/scripting(?) for git bisect'ing an issue
  • Stable Maintenance Release Schedule for the Kernel
    • The stable kernel team will change to a regular two-week release cadence. The cycle is two weeks long, and repeats every two weeks, with the exception of holidays, UDS weeks, and other considerations. An attempt will be made to sync the schedule with the needs of the Ubuntu platform schedule and Linaro release schedule.
    • There are 3 types of required testing: certification, regression and bug specific. The testing of a -proposed kernel must be completed within 14 working days begining when the upload has been accepted to the -proposed pocket.
    • Certification is the responsibility of the Platform Services, certification QA team.
    • Regression testing is the responsibility of the Platform QA team.
    • Bug specific testing is the responsibility of the originating bug author.
    • The SRU policy will be amended to indicate that changes will only be considered if we have the hardware and resources to test the fix, or a very high confidence that the bug reporter will test the proposed release.
    • Kernel stable updates will follow a two week cycle
    • At the beginning of the cycle, bug fixes, upstream stable patches, and non-embargoed security fixes will be applied, and the kernel uploaded to proposed.
    • At the end of the first week, any bug fixes which have not been verified as fixed by the reporter or by internal testing will have the patches reverted, and the associated bugs closed as "wontfix".
    • During the second week, certification and regression testing will be performed to insure that the kernel is functional. Minimum testing will insure that the kernels boots, networking operates, X starts (for workstations), and updates can be performed. Certification tests will not include the entire set of manually executed tests, but will include an automated set of tests. Testing will be a joint effort by the QA and certification teams.
    • Cert and QA will begin testing the kernels currently in proposed next week (1 Nov, 2010) and report on the amount of effort and resources required to perform testing. These results will be used to evaluate the resources required to test all expected variants of released kernels.
    • Proposed releases will be tracked with a tracking bug opened by the stable kernel team, and linked via an entry in the changelog. This bug will be assigned to the QA team (or a launchpad team - TBD), and tracked on the kernel bug dashboard. The bug will be set to verified when all QA and Cert testing has passed.
    • We need to decide which systems will be tested. Should it be most common, or some subset? It will include at least one virtual environment.
    • Security kernels which are critical or embargoed will also receive the same tests required for proposed kernels.
    • For more information: https://wiki.ubuntu.com/KernelTeam/Specs/KernelNattyStableProcessReview

    • [sconklin] boiler plate text for bug closure on failure to verify
    • [canonical-kernel-team] look at arsenal scripts to nag the users
    • [skaet][sconklin] workout the sru schedule with respect linaro and platform
    • [sconklin] provide a document that describes the process, bug tracking, and which tests are being performed, etc
    • [jfo] make sure that the bugs that we are sending for this are on the dashboard
    • [pitti] ensure verification bug update indicates that this is going to be pulled
    • [sconklin] process to add the bug to the changelog manually during release process.
    • [marjo] QA team - define a mechanism to assign the proposed upload tracking bug to them and track results
    • [victor] QA team - provide a description of what testing they provide, and an idea of the number of hours required to run those
    • [leann] provide info from HWDB http://reports.qa.ubuntu.com/reports/ogasawara/hwdb/system-stats-popular-20101019.html

    • [action] Victor to investigate which systems are "common" for cert testing
    • [cert-team] blueprint for cert-team
  • The Linaro team will be working on several hardware related tasks dealing with power management, BSP issues, root file system on flash and the like.
    • ARM Power Management
      • ondemand: come up with simple test case to reproduce problem
      • ondemand: try to reproduce on x86 to get more eyeballs
      • thermal: ensure that existing frameworks will export temperature in a standard place
      • multi-core: Verify on multicore platforms that a single thread of ondemand DTRT
      • latency: common context save/restore code from ARM
      • latency: instrument other SoCs based on OMAP work

      • latency: get latency numbers for every cpuidle-enabled platform
      • timers: log c-state information for timers that go off and wakeup system (tracepoints?)
      • SoC state names: deferred based on ARM feedback
      • governor: come up with simple test case to reproduce problem
      • governor: try to reproduce on x86 to get more eyeballs
      • hotplug: get hotplug working on relevant partner platforms
      • hotplug: pull out common code
  • ARM BSP Managment
    • Create a tool collecting statistics around BSP git trees, running checkpatch, diffstat etc.
    • Document the BSP review process
    • Do some BSP reviews for:
      • Freescale: i.mx BSP releases monthly; we should try to review each of them
      • ST-Ericsson: no official BSP release, could push for a code drop every month and review that
    • Currently two trees, but will be one generic base tree in the future and it should be the one we review
    • ARM: upstreaming patches continuously, not necessary for Linaro, already a lot of coverage
    • [dmart] to check with Peter Pearse whether there's interest in an ARM u-boot review
    • TI: 2 BSPs internally, one Android and non-Android, for OMAP3 and OMAP4, on omapzoom; monthly release; at most one kernel version behind.
    • Samsung: 1 BSP, mainstream now. Review process is work directly with mainline - probably no review needed? u-boot would need a review though
  • ARM Root file system on FLASH
    • [mwaddel] linaro-media-create changes
    • [mwaddel] Board specific info - ethaddr, serialnum, etc.
    • [mwaddel] Determine rootfs accesses
    • Use write logging on current system
    • [martinbogo] Investigation on different filesystems
    • suitability for NAND and NOR
    • performance, mount time
    • wear characteristics
    • [mwaddel] Determine current shipped file system for VExpress
  • ARM Kernel Standard Architecture
    • Will add remaining NEON bits
    • Investigation of NEON memcpy in the kernel
    • Extend SMP on UP for Thumb 2
    • Fix and benchmark HIGHMEM
    • Switch all our kernels to Thumb 2
    • (Maybe) Kprobes and dynamic ftrace for Thumb 2
    • (Maybe) Thumb 2 u-boot
  • ARM Kernel Device Tree
    • Merge existing DT support in linux-linaro and ongoing work by Grant Likely and Jeremy Kerr
    • Extend imx51 and Samsung v210 support, merge OMAP3/OMAP4 support from Grant Likey; produce demos out of these
  • Provide a hardfloat-enabled ARM port
    • dpkg
      • allocate a new architecture name in dpkg
      • triplet needs to be changed to arm-linux-gnueabi
    • vorlon to check whether buxy would be interested in doing the armhf support in dpkg as well
    • add support for armhf in lintian
    • markos to ask upstream: runtime linker path needs to be changed to have a different one between armel and armhf
    • markos to send patch to doko to enable linaro patches when targetting armhf
    • davidm to build and supply at least 6 new buildds (expected at least 8 weeks from today)
    • confirm funding for the people/resources
  • Enhancements to the firmware test suite
    • ACPI datastructures will be investigated and reported on based on the spec as to potential 'errors' in the tables
    • ACPI bytecode Methods run in userspace to determine if there are any unexpected results for sanity checking.
    • Some ACPI methods may be able to be checked offline for "insane content" (i.e. required methods which are totally empty, or methods which claim to return a value but don't actually contain any return statement at all) [kamal]
    • FWTS feature idea: "--post-resume-hook" to make FWTS run an arbitrary script after resume to allow easy repetition testing of bad things that happen after suspend-resume [kamal]
    • SMBIOS tables will be extracted and checked thoroughly for possible errors - drop using dmidecode for this task
    • Investigate uEFI testing
      • what is available?
      • what is additionally possible (runtime services?)
      • The intention is to test UEFI, but there has been no completed investigation as yet on how to accomplish this.
    • Review of bugs we curently have to see if there are any UEFI issues
    • Improve the AML syntax check test - very basic based on errors, investigate logs parsing, expand and give diagnosis/workaround
    • Kernel Log - currently hardcode table driven, put data in json formatted data file, so can be re-used by Python tools
    • Default the -p progress indicator to be on, add -q quiet flag to run silently.
    • Add post-test hook calls to run scripts after S3, S4 cycles.
    • Create a basic BIOS tracking working/broken features against vendor, version
    • Identify and push extra diagnostics patches for s/r to mainline + ubuntu kernel 'BIOS testing PPA' as appropriate
  • Handling of Deviations from Standard Kernels
    • [stefan-bader-canonical] document the why for each version deviant driver
    • [canonical-kernel-team] stable tool to detect when a directory of patches are touching a deviant piece
    • [canonical-kernel-team] document within the source tree a debian/deviant.versions type information
    • [stefan-bader-canonical] contact gregkh to see if we can use stable-review
  • Kernel Version and Flavours
    • Natty Kernel Version: Likely 2.6.38 (final decision to be made last week of Dec 2010) Advantage of 2.6.38 for linaro is an extra month to submit patches etc.

    • Natty Kernel Flavours
      • omap3 has been dropped at the moment in Natty, follow up investigation needed (see action)
      • possibility to have multiple ARM flavours
      • Do we want to consider supporting a flavour for 64bit kernels on 32-bit userspace; seems there's no compelling reason so the answer is NO
      • low-latency, is this also needed to be officially supported?; answer is NO and continue having this be a community supported flavour.
    • [] look at QEMU and determine if the versatile flavour is needed
    • [] follow up on omap3 discussion and record actual commitment from linaro
    • [jk] determine if we really need 3 powerpc flavours (powerpc, powerpc-smp, powerpc64-smp)
    • [] pull back in ports meta package into our main kernel infrastructure to simplify maintenance
    • [apw] write a skeleton document for outside consumers to reference for migrating from older versions/flavours
    • [] document officially supported flavours on a per release basis and who is responsible for those (eg ti etc)?
  • Hardware compatibility testing for Unity
    • jay/macslow - add a test for FBO & TFP; check if there is are many systems that would support only the latter and not the former

    • macslow - get infomation about reliable query mechanism in GL to obtain available video-memory
    • deliver 1st cut of detection-module to platform (jay/macslow)
    • deliver 1st cut of application-from-hell to platform (jason)
    • didrocks - provide apport support (note: see with njpatel & bryce for advices)

  • Ubuntu Kernel Delta Review
    • AUFS - still investigating a union mounts solution. still need to keep aufs for natty.
    • LIRC - Dropped, use the driver in staging
    • dm-raid4-5 - keep for natty
    • iscsitarget - see action below
    • rtl8192se - see action below
    • fsam7400 - keep for natty, but review if still needed
    • omnibook - keep for natty, but review if still needed
    • rfkill - keep for natty, but review if still needed
    • ndiswrapper - see action below
    • compcache - see action below
    • [smb] talk to server team if we still need to maintain iscsitarget as ubuntu driver or can we drop it and just use the DKMS package
    • [canonical-kernel-team] is the rtl8192se in staging, ie can we drop maintaining as an ubuntu driver
    • [canonical-kernel-team] fsam7400, omnibook, rfkill - review if still needed
    • [canonical-kernel-team] investigate DKMS ndiswrapper package. Can we get rid of ubuntu driver.
    • [canonical-kernel-team] compcache, think we can drop this but first speak with foundations
    • [canonical-kernel-team] Add back AppArmor compatability patch http://kernel.org/pub/linux/security/apparmor/apparmor-2.6.36-patches.tgz

    • [canonical-kernel-team] Review ubuntu patches for upstream submission
    • [apw/ogasawara] Add action items for specific owners to review their patches which should go upstream
    • [jk] Look at Arjan's patches to see if they should go upstream
    • [apw] After everyone's updated the wiki with comments regarding the patches which they own, clean up the git tree to match (eg drop or keep patches)
    • [jk] Review and report back to platform if there are any specific OEM patches or drivers which we need to carry

Read further notes from this track at http://wiki.ubuntu.com/UDSProceedings/N/HardwareCompatibility

Other

UDSProceedings/N/Final (last edited 2010-11-12 17:53:39 by 212-139-208-90)