There are currently a variety of ways for app developers to give us feedback on our tools and APIs, but they are not always obvious, documented, or easily accessible. Review the current options and identify new ones that will make it easier and more encouraging for app developers to tell us how to improve our offering.

The Ubuntu Developer portal has 'cookbook' pages that contain links to answered questions on AskUbuntu.com that tell how to implement a specific feature or accomplish a specific task. These are manually pulled and reviewed before being published to the site. There is a script that helps with this, but we can do much better. Brainstorm ways to improve this process, to get better content, keep it up to date, and automate as much as possible.

We now have the first release of the new API website, which provides an incremental improvement over the previous static docs. Now that the foundation is in place, it is time to grow the quantity and quality of API docs in the system, allow for community contributors to add related content and comments, and grow a community around maintaining and contributing to the site's content itself, much like we have for AskUbuntu.com

Meeting agenda and possible work items to think about:
- Investigate current apps and assess their general fitness for the Desktop.
- Based on research, figure out if we need to create a new 'use case' for a 'converged app'.
- Discuss user testing of the app, both on phablet and desktop, with Design team.
- Conduct testing of the app.
- Report bugs.
- Discuss with Design+SDK+Unity teams.
- Assign milestones to problems.

Let's review each of the core apps and there current status in regards to tests.
Are more tests needed?
Do we have 100% feature coverage?
Are new tests being added as features are added?
Do the tests run and pass reliably?

Discuss the SDK components for HTML5 app developers:
- quick update on the HTML5 UI toolkit: supported widgets, what's next
- improvements for HTML5 SDK (responsiveness, rendering accuracy, etc.)
- plans for exposing more SDK APIs in Javascript, in sync with the QML APIs
- Cordova support for creating Ubuntu apps
- also discuss ideas on how to add support for more HTML5 toolkits on Ubuntu, as the Desktop of choice for developers

Discuss how we could improve on the current status of how apps retrieve data from various places, especially webservices.
Current state of affairs?
Common services that we should be able to access easily straight from QML?
What other QML based frameworks do (BB, KDE)?

Provide materials for porting apps from other platforms to Ubuntu.
We want to provide a set of articles on d.u.c with instructions and guidelines on how to port applications from other platforms including:
- Android (general guidelines)
- iOS (general guidelines)

Followup session for:
http://summit.ubuntu.com/uds-1311/meeting/22111/core-1311-app-framework/
"We define a system framework for apps to specify for compatibility. The planned changes for 14.04 need to be defined."
https://blueprints.launchpad.net/ubuntu/+spec/core-1311-app-framework
http://pad.ubuntu.com/uds-1311-core-1311-app-framework

Go is a programming language that embraces concurrency right on a language-design level. It engraves policy decisions within the language specification and the compiler. A vibrant community of developers is using Go for developing large-scale server-side applications and successful applications written in Go have been reported all over the industry.
This blueprint covers the essential steps to enable Go for client side development, both as an integral part of the platform as well as another runtime exposed via the Ubuntu SDK.

From iOS (Apple IPhone, iPad, iPod touch) you can print, via its AirPrint facility. You simply click the export icon in nearly every app, choose Print in the menu and then you get a simple print dialog letting you choose a printer in your network, set number of copies and duplex, and then print. You need an AirPrint-capable network printer for that, or a Ubuntu machine sharing its print queues. Then the iOS device finds the printers automatically, a printer setup tool is not needed and does not exist there. There is also no driver library on iOS devices.
We will do the same thing in Ubuntu Touch. The internals are discussed in the Blueprint https://blueprints.launchpad.net/ubuntu/+spec/client-1305-printing-stack-with-mobile-in-mind. Especially we use IPP and IPP Everywhere, open standards instead of the closed AirPrint.
To make printing available in the apps of Ubuntu Touch we need a print dialog and a way to call it from the apps.
The dialog should not contain each and every option of the printer but should not be as simple as the one of iOS. The user should be at least able to choose the printer, number of copies, duplex, paper size*, paper type*, tray*, quality*, photos should be printed borderless if possible (options with * are not available in iOS, a bad design flaw, they are actually needed).
We will also need a way to print out of apps. We could do this where we export to mail, Ubuntu1, Facebook, ..., as it is done in iOS.
We do not need a printer setup tool, as the iOS devices do we will auto-detect the printers in the network (Connecting USB printers to a mobile device is too awkward).

We should have a recommended way to easily add a machine to an AD domain (other common scenarios as well. Ex: Zentyal). It should "just work". Password expiration (&notifications), changing AD passwords, lightdm set to allow logins when joined. We may also want to consider: dropping/upgrades from likewise-open, GUI for joining domain.
Could this get scheduled for Thursday?

Printing should not only work on desktop machines but also on mobile devices. We must especially have in mind that with mobile devices getting more popular for many people the mobile device is their only computing device and also that under iOS you can print from practically any application.
Mobile devices have significantly reduced resources. They do not have the space to hold a large printing stack, especially not for hundreds of megabytes of printer-model-specific drivers and PPD files. So we need to concentrate on the most important bits, ideally wit a stack not using model-specific drivers nor a printer setup tool, like AirPrint on iOS. It simply auto-discovers compatible network printers via Bonjour and users can print on them. Inspired by this I am working on splitting the printing stack to allow installation of three different levels: Level 1: Only CUPS daemon and cups-browsed, no filters, no web interface, no printer setup tool, prints only on remote CUPS queues (1MB); Level 2: Level 1 plus filters to print on IPP Everywhere (CUPS Raster), PDF, PostScript, and PCL printers, discover supported network printers automatically and just print on them (some two-digit amount of MB); Level 3: The full printing stack which we always shipped for the desktop (200-300 MB). Done in cups-1.7.1-4 and in cups-filters 1.0.44-1.
In addition, we will add functionality to cups-browsed to auto-discover IPP network printers with known page description languages (IPP Everywhere/CUPS Raster, PDF, PostScript, PCL) via Bonjour, request the printer´s capabilities from the printer via IPP, generate an appropriate PPD file and create a local CUPS queue, fully automatically, without the user needing to do anything with interactive software like a printer setup tool. This all looks like AirPrint on iOS but does not use the proprietary URF data format of AirPrint. The concept is similar: Printers get auto-discovered on the fly and appear in the print dialog and users can just print on them. Done in cups-filters 1.0.44.
Printing-related daemons (cupsd, cups-browsed, avahi-daemon) should be started on-demand instead of keeping them permanently running. cupsd is only communicated with via a socket (port 631 or /var/run/cups/cups.sock) so it could be started socket-triggered by upstart and one could easily patch it to automatically shut down when it runs out of jobs. avahi-daemon and cups-browsed should be started by the print dialog when it is opened (cupsd could be started this way, too).
When a user opens the print dialog, avavhi-daemon and cups-browsed should be started (can get called explicitly, cups should be started socket-triggered by Upstart), as cups-browsed will get D-Bus signals from avahi-daemon when printers appear or disappear and it will send requests to cupsd (gets started via Upstart socket bridge) to create or remove print queues pointing to these printers. The dialog is now supposed to watch the print queues appearing and to update the user-visible list appropriately, until the user clicks a printer. Then printer capabilities should be polled via IPP (using libcups) and if the user clicks "Print", the job is sent to CUPS (also using libcups).
When the dialog is closed, we check whether other instances of the dialog (or other avahi-daemon-using apps, how do we identify them without having an explicit list?) are still running and if not, we kill avahi-daemon. cups-browsed and cupsd keep running, we modify cups-browsed that it keeps running when avahi-daemon appears and disappears and let it remove the job-less (empty) Avahi-discovered queues if avahi-daemon disappears. cupsd closes by itself 30 sec after there are no jobs any more and cups-browsed closes by itself if it runs 30 sec without having any cups-browsed-generated print queues, meaning that all but the queue which is printing the user's job get removed when avahi-daemon is killed by the dialog closing and the remaining queue gets removed when the job finishes, if within 30 seconds no new print dialog gets opened (which starts avahi-daemon) cups-browsed closes. These non-permanent (auto-closing) modes of cups-browsed and cupsd we trigger by a special command line option or by a signal which we will introduce to the daemons and use it when calling from the print dialog (or when calling cupsd socket-triggered by Upstart).
We will also keep cups-browsed running when there are no cups-browsed-generated queues as long as avahi-daemon is running (= dialog open), so that if we open the dialog and no printers get detected we have can turn on a printer or move into a network with printer without cups-browsed terminating in the meantime.
So we will modify cups-browsed (done in cups-filters 1.0.45):
- Keep running independent of avahi-daemon running, simply remove the empty avahi-detected queues if avahi-daemon disappears and recover to avahi use if avahi-deamon reappears.
- Command line option/config file option/SIGUSR1/2 to stop if 30 sec without cups-browsed-created queues and without running avahi-daemon.
and cupsd (done in cups 1.7.1-4ubuntu1):
- Support for Upstart-induced startup: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1276713
- Command line option/env variable/config file option for stopping when 30 sec without jobs and without shared printers (default when Upstart-socket-induced).
Related Blueprints:
https://blueprints.launchpad.net/ubuntu/+spec/client-1305-mobile-print-dialog
https://blueprints.launchpad.net/ubuntu/+spec/client-1305-pdf-renderer-for-ubuntu-touch
Wiki page about PDF renderers:
https://wiki.ubuntu.com/Touch/PDFRenderer

Further evolve the notion of trusted helpers and trusted user interaction to account for requirements arising from Ubuntu's security/trust model. Trusted helpers need to be able to prompt the user for trust requests and persist the user's answer in a uniform and secure way. More to this, access to input methods and accessibility methods fall roughly into the same category as they require secure operation and UI assembling across process boundaries.

The location service as deployed on the Ubuntu Touch image today supports the notion of different location providers. It features network assisted positioning by means of Ubuntu's geoclue provider and satellite-based positioning via the Android HAL. It however lacks the following features:
* Glue code to wire up the Android GPS HAL hooks for assisted GPS to:
* Inject reference time
* Inject reference location
* Common interface to query network information:
* Wifi IDs
* Cell IDs
* Feeding the data back to positioning databases like https://blog.mozilla.org/services/2013/10/28/introducing-the-mozilla-location-service/
This session will cover the requirements for securely and efficiently wiring up all features to seamlessly support assisted GPS. On top, if time permits, we could deep dive into different stumblr approaches.

Discuss plans for Web Apps support on the desktop for this cycle. This includes:
- transition to the new dedicated web app container (model, Oxide, security/maintenance benefits)
- scope of supported web apps (ie not the whole gamut, a good part of the existing catalog should switch to being community supported)
- a word about the new heuristics used for the JS glue layer, and the impact on regression testing
- web apps settings: how to manage them (in-browser, outside) and how to simply opt-in / opt-out

We mostly stayed at Qt 5.0.x for 13.10 because of unfixed regressions with Qt 5.1.1. It's time to go forward, so let's look where we are with Qt 5.2 testing.
Bug links of interest:
https://bugs.launchpad.net/bugs/+bugs?field.tag=qt5.1
https://bugs.launchpad.net/bugs/+bugs?field.tag=qt5.2
Also need to think of backwards/forwards compatibility

Discuss the extensions planned for Online Accounts in 14.04
- support for a trusted helper
- support for applications to request an account creation if needed
- support for OA plugins in click packages and apparmor, as a way to extend the account types and authentication providers
- plan to expose OA APIs for QML & HTML5 developers
- if time permits, discussion of the webapps OA authentication scheme

By 13.10 we've got a wide selection of scopes, an easy way for developers to create new scopes and the smart scope server that returns ever more relevant results. While this is great, it's not yet there where it should be. It's still missing better browsing capabilities (to refine searches), e.g. support of departments, embedded filters or links to relevant other scopes or results of other scopes. Also, the display capabilities of both the result page/categories/dash and the preview are quite limited which does not always allow scopes developers to visualize the results in the best meaning content sensitive manner.
Goal is to resolve all those shortcomings for 14.04 Unity 8. Unity 7 will not benefit from those improvements from UI/usability point of view. Focus is on Unity 8 and phone.

This session will cover the next iteration of the infographic, the associated APIs, and the experience. Items that came up at the sprint include:
* Convert to using a directory dump rather than a database
* Installing new infographics
* Choosing infographics

The SRU process has failed for webapps; we need to discuss alternative solutions. In particular, we need to create a non-deb delivery mechanism for webapps in Desktop Trusty, so that we avoid getting stuck with Webapps SRUs for the next 5 years.

Cloud & Server

[Rationale]
Over the last few years, containers have become a powerful alternative for
many use cases to full system emulation and hypervisors. They are an
important part of our overall cloud strategy, with the goals that all
non-hardware-dependent workloads be deployable the same way in a
container as anywhere else, and that root-safe containers finally
become possible.
[Goal]
This LTS cycle will wrap up some long term feature enablement that has taken
the entire cycle.

[RATIONALE]
Juju has been in Ubuntu universe for several releases now; as its the 'preferred' deployment tool for Ubuntu Server, we should aim to get it into main for the 14.04 LTS release.
[GOAL]
Juju + required dependencies in Ubuntu main for 14.04

[RATIONALE]
Ceph continues to be a core part of the Ubuntu OpenStack platform; we should continue to ensure that it rocks on Ubuntu for the 14.04 release.
[GOAL]
Rock solid, fully supported Ceph for Ubuntu 14.04 LTS

[RATIONALE]
Juju Charms are the preferred way to deploy OpenStack on Ubuntu; we have a solid charm set from 12.04; these need updating and improving for 14.04
[GOAL]
OpenStack and supporting charms for Ubuntu 14.04; incremental improvements to support easier third-party networking and storage integration.

[GOAL]
Review all charm store charms for accurate descriptions, examples, ratings, metadata, icons, and embedded tests.
[RATIONALE]
As the charm store redesign includes new features we need to review charms to ensure they take advantage of those features. In addition, we need to ensure the charm information exposed to users in charm searching is accurate, and helpful.

If you `destroy-service` it keeps the machine around. This is terrible on public clouds as people are removing services but the machine keeps running and getting billed.
The original rationale was that not all charms use persistant data -- and we defaulted to keeping them around just in case. We need to revisit this.
James Troup points out that we've always defaulted to keeping this around, and that switching the default behavior to destroying the machine when we've always defaulted to NOT destroying the machine is also dangerous.
Discussion on this is needed, we can probably just add confirmation prompts.
DISCUSSION
* By default we agree that, when we destroy a unit, if there's nothing else running on the machine, we destroy the machine. When the last unit on a machine is destroyed, we destroy the machine.
* Some users will require the machine to stay around, so we'll provide --keep-machine to destroy-unit and destroy-service.
* Sync with the GUI, make sure the machine view takes this into account.
* Manually killing machines and how juju handles that needs a separate discussion.
* We may want to add an environment flag to change the default behavior.
* Before changing this behavior, we should have a public discussion on the list to warn people and check for unintended complications.

Juju Documentation
============
Problems with documentation
---------------------------------------------
- Features land without docs
- developers don't like writing docs
- web docs get out of sync with e.g. juju help
- developer docs also need to be published (i.e. not user facing, but architecture type notes
- docs need to be easily ingestible into new 'one juju site to rule them all'
Discussion points
--------------------------
Should docs be located in juju-core?
Advantages: easier to enforce docs of new features
Disadvantages: User facing docs should be of finished, stable features
Decision: Docs should not, at the moment, be included in juju-core
Should Docs be generated in markdown/sphinx/docbook/etc?
Advantages: developers would find it easier to submit/review docs
Disadvantages:
* Everyone has their own preferred system - whichever is chosen, everyone else would hate
* Includes an extra step to generate the format we need to consume
* None of the alternatives natively support features the current docs rely on.
Decision: Docs should remain in HTML for the present. We should investigate ways of making it easier to manage.
Still to be determined
--------------------------------
Mechanism to alert docs maintainer when user-facing features are changing

[GOAL]
Ensure that Openstack remains well support for Ubuntu 14.04.
[RATIONALE]
Openstack has been in Ubuntu for 6 releases now and is established and stable. Icehouse is the next release of Openstack and Ubuntu should have this release as well.

[RATIONALE]
The Ubuntu server seeds have grown alot over the last few years and not much has been reviewed/removed.
LTS is a good point to review and remove the surplus that is no longer supportable/important.
[GOAL]
Trimmed down server seed for Ubuntu 14.04.

[RATIONALE]
Curtin has quite a way to go before it is comparable in feature set to d-i. The changes proposed here will allow curtin to be used in a larger set of cases.
[GOAL]
Be able to install with curtin and do more custom disk layout schemes. Specifically support lvm and some raid layouts. Additionally support installing a system that will boot with UEFI.

[RATIONALE]
We'll do some work to cloud-init to make it the base for a solid cloud image. This will include enabling the vendor to do customization on first boot.
[GOAL]
Solid, fast booting cloud images that fit into many different cloud environments.

[RATIONALE]
Cloud images are important to ubuntu. They make ubuntu "just work" for different clouds. The changes for this blueprint are primarily iterative and polish. No significant changes to the functionality of the images will result.
[GOAL]
Solid, fast booting cloud images that fit into many different cloud environments.

[RATIONALE]
Percona and MariaDB are in the process of entering Debian/Ubuntu with viable MySQL alternatives.
This potentially includes Galera based Active/Active packages.
[GOAL]
Oracle MySQL to remain in main for 14.04, promotion of one active/active mysql solution as preferred/most tested/maybe in main.

Community

Discussions regarding the use of Ubuntu Desktop in an enterprise environment.
Likely to discuss authentication, configuration management, desktop automation, integration with legacy infrastructure including Microsoft products.
Notes from last UDS: http://pad.ubuntu.com/uds-1308-community-1308-ubuntu-enterprise-desktop-roundtable

14.04 will be an LTS release. Let's talk about how we can make trusty as successful as possible.
AGENDA:
-- Redefining workflows
As the QA community has grown and changed to expand and take on new roles, it's time to define a more concrete workflow for each of the roles. See https://wiki.ubuntu.com/QATeam/Roles/
Ideas:
- Outline role definitions and guidelines for each
- Create a workflow for each role
- Document workflows and roles on qa.ubuntu.com
- Communicate oppurtunities and encourage members to adopt a role
- Investigate ideas for buddy and mentorship systems, encouraging interested folks to seek out more senior members of community
- Continue classroom series and expand there technical content?
- Host hackfests aimed at teaching beginneers in each of the role basic skills for development?
-bug reporting contest for exploratory testing?

Documentation plays an important role in the Ubuntu Community and is a vital tool neccesary to the success of the Ubuntu operating system. Let's discuss and focus plans for the 14.04 LTS cycle! During the saucy cycle saw a refocus for the team. You can review the blueprint and work here: https://blueprints.launchpad.net/ubuntu/+spec/community-1305-doc-planning
Agenda:
How we can improve the "getting started contributing" process
Documenting our workflow -- changes / updates?
Goals for Trusty
Document processes (release, editing, etc.)
Immediate Tasks for starters
Audience for the docs

The Startup Disk Creator (SDC) in it's current form has a suboptimal work flow, displays to many unimportant information to the user and requires to many steps to actually create a startup USB stick. The SDC is kind of a semi public face of Ubuntu and an important tool to spread it, therefore it should be as strait forward and simple to use as possible.
This proposal is about redesigning the SDC, with a strong focus on Ubuntu and simplicity.
In the end all the user should have to do is to insert a USB drive, select an image – if there is none it should be downloadable easily – and press start.
Details (mock-ups) can be found on the wiki page.

Historically the quality team and the bugsquad have been seperate. I have proposed that we end that seperation and merge the quality community and bugsquad teams.
Let's talk about how we can implement this, the new roles, and plans for both the quality and bugsquad combined teams moving forward.
AGENDA:
merger issues
-wiki
-documentation
-skills
-launchpad team(s)
Events for trusty
-bug hugs
-papercuts project
-calls for testing

Our goal for this cycle is to have daily images tested with the ubiquity autopilot test suite for all desktop manual test entries for each flavor. Let's talk about the current progress and what needs finished.
https://wiki.ubuntu.com/QATeam/AutomatedTesting/ubiquity
Can we blocked merges to proposed based on test results?
Current tests: https://jenkins.qa.ubuntu.com/job/autopilot_ubiquity-devel/
- Push server automated tests to qatracker
- Migrate manual tests to 'optional' once automated by ubiquity testing
- Explore ideas for submitting 'generic' manual test results (ie smoketests) to tracker to be counted
- Create Long term plan for manual testcases that are no longer needed -- how to maintain or not?

With the migration to 1.4 and trusty, the core apps workflow for testing and merging into the core images still has some pain points that need addressing.
The core apps tests in many cases don't realibly run in a testing enviorment. There are several bad implications from this:
-Merge request by developers fail because a test randomly fails for code they didn't change
-Stable images can't be produced or are produced with failing tests
-True bugs that the tests find are hard to seperate from the noise (is this a random failure, or a bug?)
-Once a bug is found, the cause of the bug is hard to diagnose (platform/sdk introduced, core apps code change, autopilot, ci infastructure, etc)
Let's talk about getting the core apps tests green and running reliably. In addition, let's talk about workflow changes to revert code when the tests break in order to keep the app in good shape.

For the 14.04 cycle we want to encourage as much exploratory testing as possible. On the phone, tablet and desktop -- everywhere. Let's discuss ideas, plans, needs, etc to ensure this happens.
Review current efforts:
https://wiki.ubuntu.com/QATeam/TouchTesting
https://wiki.ubuntu.com/QATeam/Roles/Tester#Exploratory_Testing

Calls for testing in the past have revolved around coordinating with the QA community coordinator, development teams, and requiring some admin work on the qatracker, as well as announcing the test and collecting result data.
Let's make this a more open process to allow community run calls for testing. For example,
if you have a specific application / feature you enjoy or you know often regresses, schedule a call for testing and have it added to the calendar for other community members to join in and test with you. When the day arrives, each member can go through the tests and add there results. The end result will be new bugs filed (if any) / triaged and will help ensure the best success towards having a working application / feature for trusty.
IDEA:
publish community call for testing calendar
provide easy process with simple checklist for members to follow in order to schedule a 'call for testing'
use the open milestone on the qatracker; 'calls for testing' should have some form of instruction for tests

Let's talk about autopilot 1.5, and plans for autopilot during trusty.
AGENDA:
overview of tool
show off new 1.4 features
spreading autopilot love to others (how can we increase useage?)
autopilot feature requests
q and a

"our best defense is to make surveillance of us as expensive as possible"
-Bruce Schneier
What can Ubuntu do to make it more expensive to spy on Ubuntu users? This mostly a brainstorm session. Add your ideas to the notes window, but we will want you to be available to talk about the idea at the event.
Could this get scheduled for Thursday?

Google Helpout is a new platform to help users coordinate around tech support.
This session is a demo by supermatt on how they work, and a discussion on if we should use them, and if we do how do we coordinate community effort to be efficient and fun?

Participants:

chiluk (Dave Chiluk)

nskaggs (Nicholas Skaggs)

Tracks:

Community

Core

How can we cut down on build times? Here are some ideas.
CMake has a Ninja backend, which builds quite a bit faster than Make. How could we use that in package builds.
Roughly required steps:
- promote Ninja to main
- change packaging scripts so you can specify which CMake backend to use
- run ninja instead of make in the packaging build
Make would still be the default. This would be purely opt-in. The last two could be done by manually writing a debian/rules but should it be provided by the basic scripts?
A possible issue is that Ninja parallelizes automatically, so if Jenkins (or anyone) launches multiple parallel build jobs hoping they only take one processor then this will lead to trashing
Another thing to try is the Gold linker. It is currently not the default. Is there a way we could make projects opt-in to using it? In wild speculation we could also consider making it the default.

[Rationale]
Due to the use of cgroups by quite a few userspace tools, we need to get a cgroup manager in our installation to centrally handle writes to cgroupfs.
This cgroup manager has been discussed at length during Linux Plumbers 2013 and will likely be based on Google's lmctfy with addition to work under nested LXC containers.
[Goal]
For 14.04, to have a working cgroup manager, with support integrated into
upstart and lxc.

= Overview =
There are a few UI I/O issues with the current boot that need to be resolved:
- fsck feedback not being displayed:
https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/765735
https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/540645
https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/660151
- "lightdm tries (and fails) to start too early"
https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/969489
- ensuring initramfs contains all necessary fonts
https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1003480
https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1067348
- "plymouth should warn when caps lock is set with "ask-for-password" command"
https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/608954
= Plan =
Discuss the above issues and add shake out any further issues folk are aware of.
= Thoughts =
- mountall (and ideally plymouth too) need to grow a set of DEP-8 tests to validate behaviour.
- Provide a hotkey/kernel command-line option to start an "emergency console"
(see also bug 702574).
- Plymouth should exit when the boot has finished with it, not when lightdm starts (would be fixed by having system compositor).
- System compositor addresses this issue, but possibly for only a subset of graphics hardware (nvidia?)
- End-user unfriendly text-mode messages during shutdown, OEM Priority bug (logout phase fixed in lightdm)
https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/967229
Requires either system compositor, or removing output messages from offending software, or other solution to at least keep the text mode screen clean

SSDs need to be TRIMed, i. e. they need to be told which blocks the OS considers as "unused" (i. e. from deleted files). Withouth this, the write speed on SSDs becomes unbearably slow over time.
http://wiki.ubuntuusers.de/SSD/TRIM explains the details, but this kind of housekeeping really should happen by default. There are two approaches to this, immediately marking the blocks as unused when deleting a file ("discard" mount option), or calling fstrim regularly. discard slows down deletion while a cronjob occasionally puts some potentially unexpected IO load on the machine, so this discussion is primarily about deciding which approach we want to do by default.
I (Martin Pitt) think that a cron approach is better. If we go with this we need to discuss when and how to run this:
* Whats a reasonable interval (weekly/monthly/etc.)
* How to detect devices/partitions which need trimming (/proc/mounts, hdparm -I, not mounted with "discard", etc.)

We will have a lot of different upgrade paths towards 14.04, e. g. 12.04 pure, then the various 12.04.x installations with the Q/R/S enablement stacks, and so on. Right now, an apt-get dist-upgrade from 12.04 LTS to saucy is broken in many ways (backported X.org stack, lots of file conflicts, etc.).

Ubuntu is increasingly dependent on Qt5 for the phone UI, and at some point in the future Kubuntu will be moving to Qt5. Discuss how to support both of these projects in the archive when they may have conflicting minor version requirements for a given release.

We (the Hardware Certification Team) needs to deliver CheckBox improvements to Ubuntu. We need to ensure that PlainBox and the new PlainBox-based tools are properly packaged, can land in Ubuntu and can replace the old tools (where appropriate).
Finally we need an agreement about using dbus/c++ or PyQT for the client version.

In 12.04, we backported kernels, X, mesa, and DRM (and many random userspace packages that broke) for HWE between 12.04 and 14.04. Some of these things went well, others not so much. We need to deconstruct the pros and cons of what we did, figure out how we need to tweak it, and settle on exactly how we plan to provide this service for 14.04. We also need to discuss if this will cover Mir/Unity8 phone/tablet/desktop converged platforms, or only the classic X/Unity7 platform we plan to ship as the default desktop.

This is the usual UDS session where we review the past release and discuss the one ahead.
Things we should look into:
- Confirm the current release schedule makes sense
- Get volunteers for the various milestones
- Evaluate the performance of our New, SRU and MIR process and discuss ways to improve those when needed.
- Anything else that's relevant to the release, sru, mir or cdimage team

We took a bit of a break in active Python 3 porting for Saucy, but now that we're in the 14.04 LTS cycle, we want to concentrate again on this important task. There are three general categories:
* Remove Python 2 from the Touch images
* Remove Python 2 from the default desktop images
* Remove Python 2 from the default server images
Much has been done by upstreams and Debian in the meantime, so now we need to re-evaluate the work needed for Trusty.

The CI Airline is the CI team's plan for building a better workflow for landing tested software in Ubuntu.
Didier will walk us through the plan at a high level, then we'll spend the remaining time answering your questions and addressing your specific needs.
We've already done a fair amount of planning, so if you'd like to get up to speed beforehand so you can ask specific questions about the implementation, feel free to branch lp:ubuntu-ci-services-itself and read through the docs/ directory.
=== CI Airline Components ===
- Launchpad components: Merge proposals, branches, PPAs, distro archive.
- Project Manager: Contains project centric knowledge such as location of trunk names of integration tests, point of contact, etc. Also knows status of current MPs being built and a queue of MPs to process.
- Ticket System (sub-function of Project Manager): Service to create, monitor and manage ticket related activities.
- Ticket Environment Setup (now just a function of the ticket system): Creates bzr feature branches and PPAs to service a ticket.
- Tests Database (sub-function of Project Manager): Repository of tests per project. (What else?)
- Web Server: Provides human interface into the CI system.
- Branch listener: Track MPs and the trunks for the components involved in a ticket. tarmac-ish.
- PPA assigner:
Workaround LP limitations:
* We need 2 empty PPAs for each ticket (the isolated one for the ticket’s feature and one for the mer to trunk attempt for the feature)
* Since LP cannot fully remove a PPA (it will be in the database forever), we’ll manage a pool of PPAs that can be reused and will be cleaned when a ticket is closed.
- Landing Manager: Coordinates merges into trunk, ensures that all changes to trunk are built and tested in serial. Blocks access to a project’s trunk branch when a ticket or direct-to-trunk MP is being processed. Merges the changes on a successful build and test.
- Branch/Source Builder: Manages a build of a branch. Creates a source package from a given MP and dispatches it to a PPA for building and monitors for completion and collection of results.
- Image Builder and Store:
Create a new image by:
* extracting the base image
* adding the needed packages
* repacking the image
- Integration Test Service: Performs testing given some mix of packages and PPAs, or an image and tests to run.

There are cases with the phone where the battery power is not sufficient to boot (1% and lower) . Android very agressively blocks the boot process showing a charge animation. We want to do something similar (to prevent teh battery from being damaged) but easier to override (there is no need to block booting if you already have 5% battery and are connected to the charger for example) and a lot less agressive. this function needs to live in our initrd.

For certain bits if the boot process we need to be able to inform the user about things going on (i.e. extremely low battery that prevents a full boot, certain non standard boot steps that might need to give feedback to the user or delay the boot etc)
Some of these bits require visual feedback from within the initrd, others need graphical output before Mir or lightdm are up. Discuss which solutions we have for this and find the best one to implement (androids pixelflinger, plymouth framebuffer support etc)

With trusty we want to have a proper option to enable develoiper mode in the UI, have all insecure bits off by default (adb access, ssh access) and put it in the hands of the user to enable them via a settings app option.

We want the emulator to be our main target for testing an development. This session is to discuss the current status of the emulator, and the remaining work to integrate it at our development/CI/SDK stack.
Topics:
1. bringup (including MIR)
2. emulator packaging/distribution (as part of SDK?)
3. phablet-tools support
4. image production
5. OOB adb support (hopefully magic)
6. appdev test/iteration tools, documentation and best practices
7. x86 support (archive, image, emulator-x86, phablet-tools)
SDK:
1. SDK emulator user experience story
- maybe a write up and publish a user story
- once we get close to release of emulator support, run a
documentation/education campaign through blogs/social media
2. out of the box qtcreator emulator experience
- instead of working against a connected device you want use an emulator
- should be the default device if user doesn't select anything else
- super simple and robust experience
- emulator for easy testing code on phone and tablet formfactors
CI:
1. upstream merger emulator support
2. daily-release emulator support
3. image smoke emulator support
4. generic test service emulator support

Discuss how to deliver plugins over Click packages
Colin has hashed out the Click requirements already, and it should all be doable with the current system-level and user-level hooks.
There's a detailed plan for Unity scopes at:
https://wiki.ubuntu.com/SecurityTeam/Specifications/ScopesConfinement
But there are other plugin types we want to consider:
* GStreamer codecs
* location-service plugins
* any other?
These would most likely be system-wide (per device rather than per user)
Security? What kind of confinment?
Appstore integration? How do we search / hide specific Click types? How do we review these?
End-user experience? how is installation triggered? how do users manage installed plugins? Do we provide a specific API for this?
===
Notes from vUDS
https://blueprints.launchpad.net/ubuntu/+spec/core-1311-shipping-plugins-as-click:
Discuss how to deliver plugins over Click packages
Colin has hashed out the Click requirements already, and it should all be doable with the current system-level and user-level hooks.
There's a detailed plan for Unity scopes at:
https://wiki.ubuntu.com/SecurityTeam/Specifications/ScopesConfinement
But there are other plugin types we want to consider:
* GStreamer codecs
* location-service plugins
* online-accounts accounts
* Friends plugins
* desktop webapps in Unity7 (this is in another session)
* greeter visualizations (in discussion)
* app themes?
* sound themes? other themes? -- not really plugins
* any other?
These would most likely be system-wide (per device rather than per user)
Security? What kind of confinement?
Appstore integration? How do we search / hide specific Click types? How do we review these?
End-user experience? how is installation triggered? how do users manage installed plugins? Do we provide a specific API for this?
Current Click profiles:
* unconfined
* webapps
* regular apps
Upcoming profiles:
* local scopes
* network-using scopes
Unity scopes would be user-level, it would be possible to install for all users or not
For certain use cases, the effect might be system-wide all the time -- always visible to all users
As much as possible, we should design services to be extensible on a per-user basis
TODO: Loic check whether location-service is system-wide or per-user
How do we confine location-service?
- do we need to confine them at all, or do we rely on partner engagement?
- not that many plugins to review
* To implement codecs or location-service, we could offer a search feature to apps, but apps would just point the user to the right package(s) to install from the store
* Might need search API from the store
* For codecs specifically, we need to review the codecs because they are available to all apps
* For codecs, we'd likely start from .deb and wrap them into Clicks
* Security-wise, we should look at each use case independently and decide how we confine things
Adding metadata to packages might need a specific extension to click's PackageKit plugin in order to be able to search for it; "what_provides" should be the interface name
For themes, we probably only need to extend review scripts to check/validate the data, or reconvert the data, but nothing more
Online accounts: confinement not implemented right now, so would have to be manually reviewed, or specific agreement
There's a plan to move online accounts plugins to run in a separate process so we'll be able to confine them individually (and therefore not require manual review or specific agreement)

Design

We will be launching a resource hub on the website. This will be our first mobile designed website and we want to share with you want we have been doing, challenges we encountered and what we will be doing next!

We've just launched the Ubuntu Resources alpha site, our first mobile-first project. We'd like to talk about the process of designing a responsive site, show you the current web style guide we've been using for the main www.ubuntu.com site and other sites, how we're thinking of adapting that to become responsive, and how we can make these projects more useful for everyone

The design team hosts a biweekly app design clinic on Ubuntu on Air.
The clinic is a chance for you to get feedback on your app’s UI, and a forum for you to ask questions about interactions, the Ubuntu brand and guidelines, visual styles, typography, colour… anything design that you want to ask.
If you would like feedback on a particular design, send a screenshot or mockup of your design to design@canonical.com before 1pm UTC on Tuesday 19 Nov.