Q&A / BoF on Qt Project governance, community, contributions, state of the project, etc.

A session to discuss the options surround control of an Ubuntu TV from a local network. Example: a remote control app on another device and an EPG guide on another device.

Tasks from daily community roundtable sessions

We had tried to get some shortcut changes during the Precise cycle. Some successfully, some were not (like changing the "change worspace " keybindings). I propose a healthy check session/discussion with the design team to see what changes will be done for 12.10, what we need to expose on gnome-control-center, reviewing what we already expose there. Also, what changes are needed on the window manager side to propose more than one (configurable) keybinding to not break past conventions with new proposed ones.

= Summary = General discussion on the direction Upstart is heading in. = Ideas = - interactive boot. - full Upstart and SysV segregation (+ Upstart controlled shutdown). - event log for problem determination. - 'initctl kill <signal> <job>' - enabling user jobs. - introducing user job logging. - mountall plans. - custom actions. - cron replacement. - conditional start/stop on condition, based on whether a particular job is available for. Examples being:   - dovecot+postfix   - nis+autofs - ...? = References = - https://wiki.ubuntu.com/Upstart/Ideas - https://lists.ubuntu.com/archives/ubuntu-devel/2011-June/033402.html - https://lists.ubuntu.com/archives/upstart-devel/2011-August/001707.html = Blueprints = - https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-upstart-service-readiness - https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-upstart-overcome-ptrace-limitations - https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-upstart-for-admins - https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-upstart-convert-main-initd-to-jobs - https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-upstart-roadmap

Tasks from daily community roundtable sessions

In this session we will be discussing the improvements planned for the Ubuntu multi-monitor user experience. The design specification can be found here: https://docs.google.com/a/canonical.com/document/d/1aHvJ-iIw-59bXTYBmIhQqEx0za2h9jpFE_RhZ2VOvJc/edit Come along to share your feedback and ideas.

Corporations deploying Ubuntu Desktop instances face a number of issues in adopting it in their environment. The major pain is Microsoft tools that mostly dominated the backend infrastructure - Active Directory, Exchange, LiveMeeting, Office and other.

Discuss what went well and what didn't go so well in terms of QA - Release team communication during P and try to put in place the actions for smoother milestones during Q.

With the release of Essex on Precise we wish to regularily provide timely updates to our users who are still using Essex. The purpose of this blueprint is to figure out the process and track work that needs to be done.

Things to accomplish for this cycle

Tasks from daily community roundtable sessions

Playing nicely with others, adoption/migration

Reviewing and discussing all the feedback we've received on the CoC V 2

= Summary = Upstart is not currently able to retain state across a re-exec. Re-exec is useful in the following scenarios: (1) The version of Upstart is upgraded. (2) An Upstart dependency (eglibc, libnih) is upgraded. (3) Upstart is run from the initramfs. Without full re-exec support, upgrades are complicated significantly. An example: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/985755 Problem here is that upgrading from lucid to precise causes errors since the version of Upstart *running* is older than the version of Upstart *installed*. Full re-exec handling would resolve the problem as that would allow the post-inst script to re-exec upstart such that the running version == the installed version. = Details = The problem is no so much the re-exec - that's easy to do, but that on re-exec, the new instance of Upstart needs to retain the state of the old instance (difficult). This state-passing would be critical to having Upstart run in the initramfs for example since without it, the main system instance of Upstart would have no knowledge of existing jobs started by Upstart in the initramfs (for example plymouthd). = Plan = - create a pipe. - fork. - child creates socket and listens on it. - child passes details of socket back to parent via pipe (or could just use well-known location). - child closes pipe. - parent re-execs itself (closing pipe), passing a cmdline option to notify init to read from the socket. - child sends meta-data on existing jobs through pipe. - parent parses meta-data and initializes data structures based on this info. Plan is to use JSON for structured representation of meta-data. = Perceived issues = - Cannot restore D-Bus connections. This might not be an issue for the initramfs scenario since there shouldn't be any, but is an issue for Upstart upgrades. - New version of init being exec'ed must understand all historical JSON syntax quirks if we ever change how we represent objects. - Child must send its version to the re-exec'ed parent and if that parent detects the child is newer than it, state passing would be usafe since this scenario is indicative of downgrading the Upstart version. In such instances, the best course of action may be to: - generate a warning - log the childs state to a file - re-exec with no state-passing. - adding an extra library dependency to /sbin/init is a concern. - existing JSON libraries may be unsuitable for boot - would need to select a library with very clean code and comprehensive tests. - should we implement a JSON subset parser in NIH for safety? - time cost (code+tests) may be prohibitive? = References = - https://bugs.launchpad.net/upstart/+bug/348455 - https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-event-based-initramfs - https://lists.ubuntu.com/archives/upstart-devel/2011-August/001707.html

Since Mark Shuttleworth's writings of Ubuntu on mobile devices [1] there will be more and more interest expressed in what hardware is most useful and which software components lead to wh at user experience. This blueprint serves to measure the progress of Ubuntu development toward mobile use cases. Anything concrete can be included in a test plan, otherwise discussion likely involves sharing of knowlege and new ideas. For example, regarding the 'magick rotation' software, just how stable is it and relevant will it continue to be? What are the most important features of Ubuntu on Android and how is this part of the larger goal towards mobility? Being that UDS includes 'Desktop' and 'Server' tracks but nothing relating to mobility, this blueprint best fits between 'Design' and 'Other.' [1] http://www.markshuttleworth.com/archives/820

MOTU's current mission has been defined as: * Maintaining packages that do not belong in any package-sets. * Providing guidance and training for new generalist developers. * Extended Quality Assurance functions. Are we living up to this mission? What plans do we want to make for the Quantal cycle?

Discussion of plans for improvements to the Gwibber service in 12.10 The Gwibber backend needs some re-factoring to make it more testable, robust and faster.

Some devices that it's interesting to run Ubuntu on cannot do package-by-package updates for various reasons. Discuss what a solution looks like for implementing this with updating by way of swapping full OS images, various pitfalls associated with not running package maintainer scripts on upgrade, etc.