Final

Differences between revisions 14 and 15
Revision 14 as of 2010-11-02 21:52:05
Size: 24444
Editor: 99-156-85-10
Comment:
Revision 15 as of 2010-11-02 22:02:31
Size: 24445
Editor: 99-156-85-10
Comment:
Deletions are marked like this. Additions are marked like this.
Line 49: Line 49:
 * We will make numerous improvements to the Ubuntu Cloud images, that include expanding support for use on [[http://aws.amazon.com/ec2/#instance|Cluster Compute Images]] on [[http://aws.amazon.com/ec2/|Amazon EC2]] and added support for [[http://www.rightscale.com/|Rightscale]] in {{{cloudinit}}.  * We will make numerous improvements to the Ubuntu Cloud images, that include expanding support for use on [[http://aws.amazon.com/ec2/#instance|Cluster Compute Images]] on [[http://aws.amazon.com/ec2/|Amazon EC2]] and added support for [[http://www.rightscale.com/|Rightscale]] in {{{cloudinit}}}.

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.
  • Quickly will see further development, including better Glade integration, support for installing to /opt, and the Launchpad team are providing support so PPAs can be created by Quickly.

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.

  • For years now, the Ubuntu Server has tried to perform a balancing act, aiming to provide a feature-full, useful server while being as trim as possible. In doing so, we landed somewhere in the middle ground where few people are happy with the default package set, thus failing to meet the needs of our users. To solve this problem, we will look into creating a two-stage Ubuntu Server installer experience.
    • The 1st step will be focused on getting a minimal server up and running as fast as possible, for the system administrator who knows what he/she wants.
    • The 2nd step will be made optionally available immediately after first login. If utilized, system administrators will be able to easily customize their server based on the workloads they intend to use it for.
  • 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

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

Performance

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)