A Developer Membership Board Meeting. Ideally, processing any applicants present at UDS. Otherwise, meta discussion.

Roundtable sessions of the Community team.

Discussion on how we can do a quick (and possibly dirty) archive build for new hardware. The port may require new patches to the toolchain and/or kernel. Cross compiling is essential, as the new hardware may not be available. Most other packages will remain as-is, but may need a recompile with the new toolchain. We should be fine with a very minimal initial package set. Perhaps minbase? Support for "rapid bringup" archives will be variable. The general use-case will be for proof-of-concept code while full support for an official archive is in progress.

Morning sync to discuss sessions to attend during the day and review any sessions attended the day prior.

Open roundtable to discuss any Ubuntu App Development topics that might or might not be in the schedule.

Create infastructure and documentation in support of the emerging automated testing community within qa

Google Cloud Print allows printing on your local printers from whereever you can send jobs to the Google Cloud Print service, especially from mobile devices, like smartphones, tablets, and computers running Google Chrome OS. For Cloud Print support under Ubuntu we need to consider both server and client side, as Ubuntu can be used on a desktop or server machine with a printer set up or also on a mobile device from where we should be able to print. Server: Google itself only offers to either use HP ePrint printers (network printers which can receive print jobs by e-mail) or to use the Chromium browser as server to share the local printers to Cloud Print. The latter is officially only supported under Windows and Mac OS X, but under Linux it can be enabled through a secret "Cheat Mode", entering the URL "about:Flags" and enabling the “Cloud Print Proxy” entry, then clicking the menu button at the upper right and selecting "Settings", opening the advanced settings and there will be a "Google Cloud Print" section near the end of the list. So these methods are awkward, running a full-featured browser only to make available ones printers or to have to use a printer out of small choice of models. There is also a "cloudprint" package in Universe which is a small lightweight command line tool to replace the Cloud Print functionality of Chromium, but usual desktop users are not aware of that. What we would need is something like a capplet in GNOME Control Center to (de)activate and configure Google Cloud Print or an appropriate entry in the Google accounts section of the "Online Accounts" part of the System Settings. This GUI elements need to be designed and it also needs to be decided which user daemon will be used to enable Cloud Print, the one of Chromium, the "cloudprint" package. some already existing user daemon of GNOME with Cloud print patched in, or perhaps a completely new user daemon. The protocol is know and can most easily be found in the source code of cloudprint. Client: For using Cloud Print as a client applications must be able to send jobs into a queue in the cloud. Such queues are user-specific and not system-wide as they depend on the Google account of the user and not on anything local. Therefore the Cloud Print queues cannot get made available through CUPS queues without major changes on the CUPS architecture. Instead we should implement the Cloud print client access in the print dialogs (GTK, Qt, LibreOffice, ... how was it with the Common Print Dialog?), for example as a backend for the GTK print dialog.

The biannual catch-all X discussion session. If you are involved in a project that directly depends on the X stack, or needs a particular feature from the stack, come along. No specification will be written for this (any work significant enough to warrant a spec must be split out to separate blueprints). This blueprint will be used for tracking any stray work items that don't fit in elsewhere.

Fedora is doing it. Will reduce archive size tremendously. Will help Debian to consider the switch for squeeze+1. Dpkg supports it already in 12.04LTS.

Demonstrate U1DB, the synced database for Ubuntu and other platforms, and answer questions.

Executive Summary: The main idea is to make discovery of Ubuntu community automatic, and not an accident. Community is meant in the whole and general sense of "anyone who uses or contributes to Ubuntu." (In this context, community is not meant to be restricted to LoCo teams.) If we can drive more people towards the Ubuntu user&contributor communities in-real-life, then we can begin to harness the energy of the millions of people that enjoy Ubuntu every day. No other OS in the world can currently do that. Let's be the first. Problem Statement: "Houston we have a problem." Most people who have discovered Ubuntu community have done so accidentally. Most people (who are on the other side of the chasm) have no idea that community is central to the growth and development of Ubuntu. Most people have no idea whether others in their town/city are using Ubuntu. We need to make community obvious and make community formation easy. Proposal: One possible solution is to create a "Community Lens" or (similarly obvious desktop element). Make it prominent. Connect it to one's local community, beginning with those who use and enjoy Ubuntu in our town/city. Over time, expand it to include additional nearby non-Ubuntu social connections: family, friends, neighbourhood, city... https://wiki.ubuntu.com/MakingCommunityObvious

Python 3.3 was released on September 28, 2012, unfortunately not in time for it to be the default Python 3 in 12.10, although it is available as the python3.3 package. We should make Python 3.3 the default version of Python 3 for 13.04 through 14.04. Long term, if history is any guide, Python 3.4 could be released by March 2014, which is probably too late for 14.04 LTS, although we should make the alphas/betas available early in that cycle and switch to the final release by 14.04 final. Python 3.4 should probably *not* be the default Python 3 for 14.04. This is a continuation of https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-python33

How can the Ubuntu project do a better job of describing, encouraging, and including design work from interested people worldwide? Specifically, how should we: - List and promote work that needs doing (e.g. Launchpad, Harvest), in time for people to get involved - Collect design suggestions (Brainstorm, ubuntu-artwork@, DeviantArt) - Work collaboratively on designs (e.g. Onotate, Mockingbird, Google Docs) - Track the difference between design and implementation Previously: http://www.jonobacon.org/2012/10/16/growing-our-design-community/ https://blueprints.launchpad.net/ubuntu/+spec/other-design-n-community https://blueprints.launchpad.net/ubuntu/+spec/other-design-n-design-in-open-source

Create a new section on the App Developer site to present video tutorials, workshops and presentations that have been recorded as part of Ubuntu App Developer events

The DAT has been becoming better and better organised, still we need to fix the following things to be able to better accompany new contributors: - define checkpoints (first upload, ready for membership, ready for upload rights, etc.) - find changes in contributor status more easily (went inactive, might be ready, etc.) - bring more regularity in fulfilling our tasks - sync our task of helping contributors to apply with DMB meetings

What's GOing on with Juju?

We should review how well onboard is working and review the performances/feel on a device/bugs. It could also be an idea to compare it with the other available solution: caribou (the one used by GNOME), maliit, ...

Kubuntu docs plans for raring.

Topics for #ubuntu-classroom for R

qemu-kvm is the preferred hardware emulation platform in Ubuntu. The goal of this work is to follow and help test upstream development, collaborate on bug fixing with upstream, and ensure that kvm is stable and fullfills our needs. In this cycle, we will focus on merging divergent source packages into one, and re-syncing our packaging as far as possible with Debian. This should result in increased testing for arm users, reduced duplication of effort between qemu-linaro and qemu-kvm sources, and increase collaboration with Debian. Etherpad: http://pad.ubuntu.com/uds-q-servercloud-r-qemu Blueprint: https://blueprints.launchpad.net/ubuntu/+spec/servercloud-r-qemu

Canonical has announced a new 5-year LTS support policy for the Ubuntu Desktop which will provide updates to X, drivers, and necessary plumbing layer components to provide support for newer hardware in the LTS. There are still some open questions on implementation though, so additonal discussion on the implementation is warranted. * What packages will be backported unrenamed? - Discuss xserver-common, libxrandr, xrandr, x11proto-* as needed, wayland, llvm-3.1, libdrm (with intel patch re-instated for arm?) * Review and sru changes to build current xxv packages against newer libdrm - mesa, xserver-xorg-video-nouveau are affected, maybe plymouth as well * Review tasks left over from https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-xorg-lts-updates

bibisect has been proved to be very helpful for Libreoffice development: http://nabble.documentfoundation.org/What-is-bibisect-And-what-is-it-doing-in-my-office-td3572953.html http://sweetshark.livejournal.com/7683.html As LibreOffice maintainer I see regular breakage of my package triggered by other uploads as LibreOffice has more than 900 build dependencies alone (so 1/3 of main). I have seen LibreOffice being broken by: - gcc becoming ABI incompatible - boost1.49 having a heisenbug regression against 1.48 - libjpeg being moved to multiarch (build between my local build and the time that the buildd got its slow to build libreoffice) - kernel corrupting the application stack on swapping with encrypted home/swap - a minor kde microrelease adding a new define in a header To triage such painful bugs, the ability to get "back in time" would be immensly helpful on Ubuntu too. This is especially true when multiple bugs caused by different uploads stack upon each other. Also, easily doing a clean build from scratch (as gentoo does with stage1/2) might be helpful in such situations.

Informational session on Edubuntu Server. If you want to learn more about our plans for Edubuntu Server in 14.04 LTS, come to this session. Announcement for Edubuntu Server can be found here: http://www.stgraber.org/2012/10/21/edubuntu-the-path-to-14-04-lts/

From Oneiric on we are using GNOME 3.x and from this GNOME version on there is a printer setup tool in the Control Center. This tool is new and has much less features than system-config-printer and especially does not contain all the functionality for selecting best drivers, identifying network printers, HPLIP integration and so on. So dropping system-config-printer in favor of GNOME's new tool will be a major step back. Discussion has already started on the OpenPrinting Summit in April this year (see links below) and on the UDSes for Oneiric and Precise. Here we will continue discussing the situation to see how the situation improved with the further development of the new tool. Our plans are to finally switch over in Raring. In Oneiric and Precise we have continued to use system-config-printer, patching and configuring gnome-control-center and the system menu so that system-config-printer is started in its own window instead of the capplet of the control center, at least for Unity desktops. For Raring we want to finally use the original GNOME tool. The support for setting option defaults, especially the configuration of the printer's hardware (accessories like extra trays, duplex unit, ...) got added, but we need to take care about the following items: - Server Settings: Share printers, accept shared remote printers, debug logging, everyone can kill everyones jobs, remote admin, ... - Correct printer/driver assignment, joining auto-detection results of the same device, ... using system-config-printer algorithmic part via D-Bus. - Auto-configure hardware add-ons of PostScript printers using the functionality provided by CUPS. - Printer driver auto-download via OpenPrinting - Plug'n'Print (fully automatic setup of USB printers) See also: https://bugzilla.gnome.org/buglist.cgi?component=Printers https://bugzilla.gnome.org/show_bug.cgi?id=654742 https://www.linuxfoundation.org/sites/main/files/system-config-printer-status.pdf

Many users feel like their city is left out when choosing timezones. To that end, we have incorporated geonames data, and when connected to the Internet, indicator-datetime will go out and get data from the web for any large municipality. However, this does not solve the problem for those that are not on the Internet at the time they are using it, as is common during install time where indicator datetime is used to choose the timezone. This blueprint is to discuss the best way to augment indicator-datetime to solve this problem

Review the buildd resources available for the distro builds and various test builds, discuss buildd uses outside the core distro team (like daily Go builds, and unity test builds). - priorities for non-distro builds in times when the buildds are needed for distro - armhf buildd resources. even after stealing armel buildds, the test rebuild did last more than three weeks - temporary resources for test rebuilds for the whole archive. while main can be done on a weekend, universe takes too long. being able to add two more buildds for amd64/i386 for the time of a test rebuild would help. [re-submit for UDS-R]

Discussions about continued Ask Ubuntu integration and other Ask Ubuntu related tasks...

Discuss how +1 maintenance will work in Raring: staffing, priorities

One common problem with priinting is that the print filters take a too long time to render the pages to be printed. This gets especially a problem with Ubuntu making it into mobile devices. This caused by applications generating too complex PDF when printing. For example if you display a PDF not containing transparency with evince and print it, Cairo sends a new, much more complex PDF with transparency to CUPS. Application and toolkit developers must get aware of this and improve the situation, both for making printing quicker and saving battery life of mobile devices.

The current powerpc kernel state is stagnant and based on there only being PowerMac and IBM P-Series kernels. With the expansion of Power into various other vendors and the availability of many types of machines, this needs to be expanded. However, this may incur patches that are not PowerPC centric, so the possibility exists where the power kernel may need to be built separate from the stock kernel package in Ubuntu. DIscussion is needed on the best way to proceed, best practices for maintaining it and best methods of supporting as many alternate Power CPUs/SoCs as possible while keeping the package maintainable. == Comment == Hi Ben, Currently the session shortname (powerpc-kernel-devel) doesn't fit the convention for the tracks. Would you be able to determine where you think this best fits? -- Daviey Changed to hardware-r-powerpc-devel -- BenC

Learn what Accomplishments are and how to write them. We will cover both stand-alone scripts that are checked by the verification daemon, as well as how to add accomplishments directly from your application. Bring your laptop and we'll have you setup and writing your own accomplishments by the end of the session!

Our usual session for feedback on changes from the past cycle and disucssion on the upcoming changes for the next cycle. This covers both the foundations side of things (ifupdown, isc-dhcp, ...) and the desktop side (network-manager, modem-manager, ...). Initial list of topics: - Local resolver on desktop installations - DNSSEC support - Caching support - How to support people running their own DNS server (do we care ?) - IPv6 support status and next steps - IPSEC - UEFI secureboot netboot on IPv4 and IPv6

The kdump mechanism from the kdump-tool package is more flexible than its kexec-tool equivalent. It allows for multiple dumps to be collected, is the mechanism used in upstream Debian and has a configuration file that let the sysadmin controls some parameters. It is currently functional on Ubuntu but the documented way of gathering a kernel dump is to use the 0_kdump initscript delivered by kexec-tools which package the kernel dump file as an Apport bundle. While this solution is sufficient on Desktops, it becomes restrictive on server/cloud installs. Rationale: Current kexec-tool kernel dump capture mechanism is too limitative in a server/cloud environment Goal: Decide on the feasibility of using kdump-tool as default for server/cloud installs

Audio latency is relatively high on Linux and we need to be competitive with other platforms.

We will make a follow up to session on coverage https://blueprints.launchpad.net/certify-planning/+spec/cert-r-13-04-coverage to cover server specific features

Planning the Xubuntu R release.

The QA teams feel that there is a need of a unit testing suite so that those tests can be run as autolanding tests, and the autopilot test cases should be used later in the development cycle.

The plumbing layer for hybrid graphics support is now roughly feature-complete. We are now in a position to expose this support to users, via the Unity desktop environment, which means we need some UI and some policy. We need to know which applications to start on the powerful GPU, and users probably want some power-dependent policy to influence this decision. This session is to discuss the design and implementation of the user-facing component of hybrid graphics.

Devices which ship with Android require OS images to come in a particular ROM format. Ensure that generating these images is well-supported in the cdimage.ubuntu.com pipeline.

Review the current state of hybrid graphics and what's feasible for 13.04. - Prime power management expected in 3.8 (http://cgit.freedesktop.org/~airlied/linux) - Review dual-boot scenarios for said power management. Current git code will leave the GPU in a bad state that persists into a Windows reboot. Card will not work properly unless first rebooted into a non-power managing kernel or the battery is pulled. - On-the-fly gpu switching expected for xserver 1.14 (http://cgit.freedesktop.org/~airlied/xserver) - DRI2 offloading implemented in 12.10 does not work properly. Performance is poor and most things will not render. (awaiting SRU or upstream?) Old blueprint for reference: https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-hybrid-graphics

Organize and run the next App Developer Week with live hangouts

Every UDS we have a Cloud Image Roundtable, Cloud Init Discussion. This UDS, we are going to consolidate the discussion of Cloud Images and the interaction with Cloud Vendors (including Cloud-Init and vendor tools). Cloud Images: * Carry over of recue images volumes from UDS-Q * Switch to UUID's instead of labels * Disk formats, or provide scripts for easy conversion between tools * Discuss usability of Cloud images in LXC and stand-alone KVM Cloud-Init: * Add short-hand for installing cloud vendor packages * Add support for IAM per-instance credentials * Customization of when Cloud-init runs? Package More tools:    - Cloud Meta-packages to install specific tools    - AWS       - Import/Export [1]       - CloudSearch [2]       - Elastic BeanStalk [3]       - MapReduce [4]       - SNS [5]       - Minor (single tools)           - CloudFront [6]           - Route 53 [7]    - HP Cloud        - Ruby Tools [8]    - Windows Azure Tools        - NodeJS CLI tool [9]        - Not packagable due to dependencies on NodeJS - Perhpas packe a helper script?    - Google Compute [10] Reformat cloud-images.ubuntu.com to use same Ubuntu.com format. [1] http://awsimportexport.s3.amazonaws.com/importexport-webservice-tool.zip [2] http://s3.amazonaws.com/amazon-cloudsearch-data/cloud-search-tools-1.0.0.1-2012.03.05.tar.gz [3] https://s3.amazonaws.com/elasticbeanstalk/cli/AWS-ElasticBeanstalk-CLI-2.1.zip [4] http://elasticmapreduce.s3.amazonaws.com/elastic-mapreduce-ruby.zip [5] http://sns-public-resources.s3.amazonaws.com/SimpleNotificationServiceCli-2010-03-31.zip [6] http://d1nqj4pxyrfw2.cloudfront.net/cfcurl.pl [7] http://awsmedia.s3.amazonaws.com/catalog/attachments/{dnscurl.pl,route53tobind.pl,bindtoroute53.pl,route53zone.pl} [8] https://docs.hpcloud.com/cli/unix [9] https://github.com/WindowsAzure/azure-sdk-for-node [10] https://developers.google.com/compute/docs/gcutil/ [RATIONALE]: To enable the use of Ubuntu regardless of the Cloud [GOAL]: Provide native packaging for all major cloud vendors.

During the Ubuntu Release Schedule session, it was identified that a mechnism was needed to allow the flavor PM's to coordinate schedules, milestones etc... this is that session.

Goals for the Ubuntu Women UDS-Q cycle Add your ideas here for consideration in this formal blueprint: http://wiki.ubuntu-women.org/Roadmap-R

The CUPS Browsing/Broadcasting mechanism which made print queues shared on remote CUPS servers automatically visible for the local CUPS daemon and so for local applications got dropped upstream from CUPS 1.6.x on. Ubpstream has replaced this functionality by Bonjour-based broadcasting (under Linux implemented via Avahi), an OS-indpendent PWG (Printing Working Group) standard, but this lacks the implementation of browsing on the client side making the printers on remote CUPS servers not automatically appearing any more. Quantal's CUPS has a mega patch to forward-port this functionality from the old CUPS for one cycle, to avoid regressions. We cannot carry such a patch eternally, and we should follow upstream and the PWG standards. So in Raring we need the real solution which means that the print dialogs (upstream-recommended solution) or the CUPS daemon (how I like to have it) takes the new Bonjour (Avahi) broadcasts to display the shared remote CUPS queues automatically. The browsing functionality is implemented in the CUPS library (libcups) from CUPS 1.6.x on, but there is currently no production code using these functions. Upstream expects the print dialogs to use the new library functions for displaying the new queues. This would require modifications and upstream submissions for GTK, Qt, and LibreOffice at least and this does not safely cover all existing applications which have CUPS-aware print dialogs and therefore listed the remote queues before. Especially printing from the command line would not be covered. The better approach would be modifying the CUPS daemon so that it uses the new library function to find the remote queues and advertize them like its own local queues. Where the CUPS daemon needs to be patched for that we could probably derive from Quantal's CUPS Broadcasting/Browsing forward port patch. The new Bonjour browsing patch being based on the new standard way of Bonjour broadcasting has probably good chances to be accepted upstream. This feature does not only prevent a regression, but it also helps to more easily access printers connected to Mac OS X machines (they broadcasted Bonjour-only all the time) and also for mobile Ubuntu devices. Usually you do not have connected printers to tablets or phones and you carry them around between different local networks, so here it is especially important that they automatically pick up the print queues in the local network. In the session we will discuss which method to use and the implementation in Raring.

The goal is to identify ways in which we can improve the throughput of the SRU process be it reviewing packages to go into -proposed or releasing packages to -updates.

Rationale: Quickly is the recommended quick start development tool. It's important to keep it up to date and useful. Goal: Specifically this cycle, a big focus will be porting to Python 3 for both managed projects and Quickly itself.

New provisioning methods and small features that we may have missed.

With the R release we want to be able to flash ubuntu onto unlocked fastboot based android devices. The image build system will provide img files for this. To make the actual flashing procedure as easy and safe as possible, this functionality should be integrated into usb-creator which already deals with writing images to devices.

With the bug fixing initiatives in full swing we should showcase the work of new contributors to inspire others to follow their lead. Possible things we could do: - Regularly interview new contributors about their experience. - Figure out a way to track adoption and success of these initiatives.

Establish a list of current functionality that is considered essential in the Quickly reboot, and define a plan for regularly testing the reboot to assure it will meet the needs of developers

During Q cycle there have been a number of features added to ubiquity. Some of these have only been implemented for the Gtk frontend, and still need to be implemented on the qt frontend side.

A session where to discuss and plan the future of Ubuntu Studio

Rationale: By improving the basic level of testing that can be applied to all packages in the server supported seeds, we decrease the amount of manual testing effort required during the development release and to support stable release updates. This reduces the risk of changes impacting basic functionality of supported packages. Goal: DEP-8 tests for all supported server packages. UTAH tests using DEP-8 tests for testing.

How do you compile Ubuntu binaries that run in the mobile roms

How we plan on expanding community contributions to Juju Charms.

Review of the secure boot implementation for precise. Progress updates on the signed boot path, secure boot tools, and Ubuntu infrastructure. Development plans for the next cycle, areas that we left for implementation in 13.04, and backport progress for the 12.04.2 update.

UOA went from adhoc to being fun and popular. Let's figure out how we can improve the system/organization for R.