Other

Revision 19 as of 2010-10-28 16:40:37

Clear message

This page is here to collect together proceedings from sessions as part of sessions that don't fit one of the pre-defined tracks at the Natty UDS in Orlando, Florida.

Please add proceedings by doing the following:

  • Add a new section with the name of the session.
  • Add the outcomes of the session as a collection of bullet points. The goal of the proceedings is to really focus on decided outcomes, so please try to keep them crisp.

Thanks!

Proceedings

Paper Cuts for Natty

  • Vish has been doing a lot last time, but he shouldn't have to do all work. This cycle more people should help him with triaging paper cuts;

  • There will come an open Launchpad team, for everyone who is interested in fixing paper cuts. This team gets assigned to all paper cuts that are accepted, so the team's mailing list gets a mail and the team members know there is a new paper cut to fix;
  • Until other package description projects get going we should continue to accept descriptions paper cuts, but they could be moved to a separate milestone;
  • There will be a separate 'Paper Cuts'-like project for Unity, so the One Hundred Paper Cuts Project should be about applications and upstreams;

  • Paper cuts in featured applications and in applications of upstreams willing to cooperate will be accepted during the Natty cycle as well;
  • We will cooperate more directly with upstreams and Debian with regard to the package descriptions, to make sure our improvements benefit other projects as well, and we get feedback from the people who know the applications like no other;
  • Vish will select the milestones for the Natty cycle;

  • JonoBacon, JorgeCastro, SenseHofstede and Vish should generate (more) buzz at the usual channels about fixed paper cuts, including quotes from happy upstreams in the posts;

  • We will investigate the possibility of using Launchpad Translations and a custom version of US English to provide a temporary easy way to modify package descriptions in Ubuntu;
  • JorgeCastro will communicate our package description improvement effort to Debian, to make sure the Debian Developers understand what is going on and are prepared for our forwarded bug reports.

Testing Ubuntu on different architectures

  • Only the testcases with subscribers in the ISO trackers will be built.
  • Distributions will choose what architectures and "special testcases" they commit to.
  • We will have regular names for architectures and distro names.
  • The release manifest will include only the images that were tested properly.
  • All this process should be automatic
  • This change of policy will be announce to ubuntu-devel-announce

Cross-compilation Environment

  • We will pursue and extend the efforts started under the ALIP umbrella to cover a larger set of packages
  • Automation will be setup to test cross-compilation of the new package set in both in "from scratch" and "source by source" modes
  • Multiarch control fields will be used to classify packages in host versus build packages

Kexec

  • Kexec needs lot of fixes and testing on ARM, subarch by subarch
  • Will extend kexec to cover device tree
  • Some demo / test features will be implemented with kexec (kexec-reboot, boot menu etc.)

Kernel configuration management

  • Will create a dataset of config requirements as to allow tailoring the config for a distro, or for a product
  • Only machine specific configs could possibly be stored upstream
  • Needs policies for Ubuntu and for Linaro to define common configs such as networking, security etc.

ARM gdbserver support

  • gdbserver will be included in developer images
  • New package for an armel cross-gdb
  • Developer experience will include a new tool to grab debug symbols from ddebs
  • Will develop new test frameworks and safety checks

Reinvigorating the artwork team

Session identified need to start a web presence project including following activities: 1.research

  • .existing questionaire
  • .Describe problem
  • .Conduct survey
  • .Analyse
  • .gather data about lapsed members

2. Define our objective 3. Sketch solutions 4. Test and iterate 5. Launch

TASKS

  • design a questionaire - Ivanka
  • Set up fortnightly meetings - Iain/ Ivanka/ Docmo
  • move the questionaire to a central place- docmo
  • email the loco team leaders the survey- have them direct
  • publicize the survey- on blogs, lists
    • .design blog, u-artlist local, contacts list, Flickr group.

Process

Project broken up into four sprints (2 weeks each)

1st Sprint

1. Review data in central place

2. Design questionnaire

2nd Sprint

1. Get survey out there and receive input after which steps 3 & 4 can be determined.

Design in open source

A first project to kick us off while we prepare the web project is Launchpad Edit Icon

  1. Icon brief by wednesday
  2. picpick for contributions
  3. publicize
  4. two week deadline - last submission
  5. winner announced 3 days later

Defining Gestures in Ubuntu via Configuration

  • Agreed that physically literal gestures don't need configuration options

Using QEMU for demonstrations

  • many of Linaro's other outputs (kernel power management, performance, graphics improvements) are not demoable via qemu
  • we should get the Beagle XM model working with Linaro images (as a compromise between memory size/capability and being a platform Linaro supports in h/w)
  • investigate/use the paravirtualised OpenGL work done by Nokia for maemo/meego
  • good audio support is tricky -- low priority

Using QEMU for development

  • for development users we need not be modelling real hardware : we should define a "virtual platform" which is simpler and less prone to fragility in the face of kernel changes, and has more memory, fast virtual devices, and so on
  • we are effectively "filling the gap" between now and when native ARM dev/build hardware is more prevalent/cheap
  • need to test/validate qemu so it is trustable as a dev platform
  • need to consolidate qemu trees to avoid the "which qemu should we use?" problem

Ubuntu One file sharing, sync status, and UDF selection

  • Ubuntu One button in Unity launcher and notifications that something has happened (a share has arrived and needs accepting, etc) will go into the Messaging Menu
  • Need to decide how to handle shares between these options:
    • Expose the current "reject this share completely" u1sdtool feature in the GUI,

in the Nautilus folder right-click menu, clicking it completely rejects that share from all your machines

  • Change syncdaemon to allow rejection of shares per-machine (like UDFs will be handled)
  • Only provide "reject this share completely" on the web and provide rejection of shares per-machine in N+1
  • User Defined Folderes (UDFs) will not sync automatically by default
    • User will need to tell Ubuntu One which folders she wants to sync via the Ubuntu One control panel and at initial setup

Ubuntu One visibility and integration with Unity

  • Ubuntu One in Unity launcher, launching the Ubuntu One control panel (ubuntuone-preferences)
  • Ubuntu One notifications will go in the messaging menu
  • Indication of syncing will likely go in the Ubuntu One launcher item

Ubuntu One integration with Zeitgeist

  • Ubuntu One will log events in Zeitgeist and aggregate this data to display notifications to the user about important activity (content synced, etc.)
  • An ontology for Ubuntu One events will be created and documented so that other similar services can use the ontology
  • GNOME Activity Journal to support viewing events other thancreated, edited, deleted type events

Security AppArmor packaging

  • get bindings in order (have perl, want python and ruby built, tested and packaged)
  • cleanup to use modern debian packaging
  • better upstart integration. This does not necessarily mean AppArmor will use a job file, but we should make it easier for applications with job files and AppArmor profiles to load their profiles via the job file. This will likely be done via a helper

  • clean up /etc layout
  • work towards inclusion in Debian so we can get expert feedback on existing profiles as well as more high-quality profiles

Security AppArmor upstream planning

Preliminary TODO list for natty:

  • get the compatibility patches into natty - High - should be next week
  • level 1 btrfs for natty (patch sent up for review very soon and then iterated) - High
  • level 2 btrfs for natty (should be small after the first is sent up) - Medium
  • level 1 network mediation - Medium (we have a compat patch in the meanwhile)
  • send up his thoughts to the ml - Low - (we have a compat patch in the meanwhile)
  • discuss and spec out sysfs hiearchy in the wiki
  • sysfs introspection
  • fix kernel so that it will drop policy compiled on a newer kernel for which it doesn't understand(currently network, capabilities, rlimits)
  • make sure upstream initscripts or ok
  • clean out super-crufty, old log parsing stuff

Root Filesystem on Flash Storage

  • A Linaro release should be customized to deploy to a 128M flash system
  • The optimal system will avoid excessive interaction with the flash
  • The Versatile Express will be used as a reference platform - 128M NOR flash
  • Use the jffs2 filesystem (logfs should be investigated)
    • UBFS for NAND
    • Processes should be tuned to minimize writing to flash
  • A deploy mechanism needs to be developed or at least specified
  • Optimize cache write settings

Session Name

  • Outcome
  • Outcome
  • Outcome