UK Linux User Groups

Recently we had our online Ubuntu Developer Summit where we discussed a range of topics, defined next steps, and documented work items. The very last session at the event was an overall summary of the tracks (you can watch the video here), but I wanted to blog an overall summary too. These notes are quick and to the point, but they should give an overall idea of decisions made.

Client

• Content Handling -

  • Siloing apps.
  • Main applications will define a “main repo” and provide an API to deliver, share and access the data in the main repo.

• X.org

  • Want to update to 1.14 or even 1.15 if the video ABI doesn’t change.

• System Settings

  • Focus on the phone settings defined here.

• Scopes

  • Scopes that didn’t land in 13.04 should land within 2 weeks.
  • Several scopes will be migrated from Python to either C++ or Go for memory purposes.

• Chromium

  • Expressed interest in moving to Chromium as default for a better user experience. Gathered feedback on the possible move. Next steps are to take discussion to the mailing list.

• Unity 8/Mir Preview in 13.10

  • Want to have a preview of Ubuntu 8 (Phablet UI) running on Mir as an optional session (installable from universe or PPA, most likely).

Foundations

• Reviewed the current 13.10 release schedule found several changes made in 13.04 that mistakenly hadn’t been carried over, such as later freeze dates and one fewer alpha; Adam Conrad will be syncing all this up and sending mail to the ubuntu-release list for review.
• We discussed the positioning of the development release in light of some conversations last cycle, and put some more flesh on the design for making it easier for people to follow along with the development release all the time.
• This cycle, we’ll be bringing up a new 64-bit ARM architecture based on cross-building work done last cycle, and we’ll update developers on that once we get closer to the point of starting up builds in Launchpad.
• Moving forward with click packages. Fleshed out ideas on source package provision, integrating with existing client package management stacks, and clarifying some other things like the security model.
• For image based upgrades, the team held a demo and Q&A for the current proposed solution, which is split into client, server, and upgrader; client is going well and expected to land by the end of June, server is currently blocked on infrastructure but should be ready around the same time, and Ondrej Kubik has been making good progress at tweaking the CyanogenMod recovery environment for the upgrader.
• Firmed up the plan for packaging Android components for Ubuntu Touch images.
• Upstart will be used as the standard way of spawning desktop apps for Unity on touch devices and ideally on desktop too (Unity 7 and 8). This will let us make sure we only have one instance per app, and will make it easy to apply AppArmor, seccomp and cgroup confinement consistently to all apps.
• Defined a goal to reduce the amount of time it takes to prepare, test and make a Checkbox release, automating more of the process. This will benefit people who use the Checkbox tool as part of their daily work. It’s possible that Checkbox may move to Universe, although this needs some more discussion.
• The server certification tools are being reengineered to use the new plainbox engine as their core. This will preserve the existing UI, but we’ll have co-installable packages with the new core, and will eventually switch over to the new tools.
• The cert tools and test suite are being upgraded to work well on ARM for our hyperscale and mobile work, fixing any issues so we can get full, clean test runs on ARM servers. MaaS will be used for provisioning, and tested as a part of the ARM server solution.
• We will be basing the primary kernels for 13.10 on Linux 3.10, but will strongly consider 3.11 depending on timing. For Ubuntu Touch devices, we already have kernels available for Nexus 4 and 7, and plan to also bring up kernels for Galaxy Nexus and Nexus 10. We’ll provide a 13.04 hardware enablement kernel in the 12.04.3 point release.
• In terms of Ubuntu Touch power management, we have some preliminary baselines against Android on Nexus 4 and will replicate those on other devices, although they won’t be entirely meaningful until things like Mir land. We’ve written some new utilities such as eventstat to track down problems here. On power management policy, we agreed key requirements for the system power manager and we’ll extend powerd to serve our immediate needs.

Community

• Community Roundtable:

  • Approved LoCo teams are no more, will be verified teams.
  • Bringing back fortnightly leadership meetings.
  • Ubuntu Advocacy Kit is driving to 1.0.
  • Gathered UDS feedback.

• Ubuntu Community Website

  • Great discussion which clarified everybody’s involvement in the project.
  • Clear roadmap for completing the content and design in the next few weeks.
  • Design and web team have the templates we need to finish the work.
  • No discussion with IS yet around deployment – this will be coordinated next week.

• Ubuntu Womens Session

  • Several events planned to get more people involved and the word out (Career Days, UOW, etc.).
  • Discussion about a women in technology themed event at CLS.

• Ubuntu Status Tracker

  • The status tracker is many things to many different teams, but we managed to figure out a number of issues we can tackle, which should make everybody’s lives easier.
  • Removal of kanban view.
  • Add links from team pages to milestones pages.
  • Set up a meeting to discuss setting up an “ongoing” dev series.

• Ubuntu On Air! Discussion

  • Issues with supporting multiple hosts.
  • Discussion about building support into summit and re-using vUDS components to support more shows and multiple hosts.
  • We want to open it up to more contributors, so we get more variety into the shows.

• Development Onramp for Touch / Unity Next

  • Goals to improve docs.
  • We will track contributions to all the projects to see how we improve.
  • Increased focus on testing, coordination with the SDK team.

• Documentation Team

  • Update Getting Started Page, review current docs and previous mailing list feedback.
  • Regular doc review cadence and more health check meetings.
  • Focus on content in the UAK.

• Ubuntu Enterprise Desktop Discussions

  • Another meeting will be planned to get more input from users of enterprise desktops.
  • Some common issues were identified and discussed:
  • outdated cfengine package
  • access to Firefox/Thunderbird packages before publication (resolved)
  • support for livemeeting/linc

• More Ubuntu Touch images

  • We identified the current blockers and will simplify thingsby using an image without firmware blobs, so they can be added by a local tool afterwards.
  • After the rebase to saucy we will also update the docs accordingly.
  • Kernel images for devices will first live in PPA, afterwards probably in universe.

• Regular Ubuntu Development Updates

  • Organise regular Ubuntu on Air Hangouts to which we invite people from news sites as moderators.
  • Briefly summarise work from the last week(s).
  • Ask engineers to demo/showcase interesting developments.
  • Do Q&A sessions.
  • Also invite members of governance teams along.

Cloud and Server

• Openstack Next Steps

  • Looked at some high level areas for this cycle, avoiding digging into areas covered by other sessions. We decided that at current, moving over to Git for our packaging work doesn’t add value. We also agreed to clean up on some cruft within the packaging branches.

• Cloud Archive Status Check

  • Decided we had to support Grizzly for 12 months, which exposes a 3 month support gap from the backing Raring release. Need to discuss with the security team about how to fill this gap. Reviewed proposal for SRU cadence and tentatively rubber stamped.
  • Better co-ordination around trumping by Security dates, specifically if it covers more than one project.
  • Looked at using updates as a reason to increase our messaging.

• 12.04.x images with LTS Enablement Kernel

  • The cloud images currently only contain the Precise (3.2) kernel. Discussed adding the kernel HWE stack to cloud images. We need to document how to enable backports, clearly state the support, and possibly tool cloud-init to handle updating the kernel on boot if folks need a more recent kernel on boot.
  • We will not be creating new images with the HWE kernel for the default images. The HWE kernel will be used for Clouds that have a high velocity of change in the Hypervisor (i.e. Windows Azure). For the regular images, we will investigate tooling in cloud-init and other places to make the ingestion of the HWE kernels easier, such as enhancing the documentation, allowing for easier enablement of backports, and making it easier to enable the HWE kernel at boot time.

• Cloud-Init for Vagrant

  • We will create a good Ubuntu development workflow for Vagrant users (cross platform OSX, Windows). Ben Howard will investigate cloud-init tooling as well as the best method to enable the DKMS modules.

• Cloud Init & Cloud Image Development for Saucy

  • We will define the development work to improve cloud-init and cloud images for the saucy cycle.
  • Discussed work on pre-cloud init phase, vendor hooks, cloud init plugin, and rebuding tools.

• Juju Core Development

  • 1.10 version of juju available in backports for 13.04, and should be available in precise backports soon.
  • Look for releases in juju/dev ppa updating weekly, juju PPA monthly, and have stable release go into backports (couple of times per cycle).

• OpenStack Hypervisors

  • HyperV support is currently untested.
  • VMWare support in charms, but not primary supported charms.
  • We need a matrix to demonstrate interoperability and support of each variation.
  • Need to work out additional hardening support.

• Openstack QA

  • Building on our great history, moving away from per commit hardware testing to a more fluid multi virtualised separated environment, allowing greater interoperability testing. Hardware Cert term showed interest in getting more involved. The scope of this will be ratified when the interop matrix is created.

• Flag Bearer Charms

  • Will improve flag bearer charm integration testing.
  • Implement list of reference charms.
  • Develop Percona backup XtraBackup flag bearer charm.
  • Document flag bearer and reference charm criteria in best practices.
  • Discuss flag bearer charms on mailing list.

• Charm Policy Review

  • Add into policy for a charm to provide a config option to specify the version. The other items such as installation location (ie /srv), implementation of common subordinates, backups are to be added to best practices. The 3 ack on charm reviews is still under discussion.
  • Split Juju docs best practices and policy sections.

• Audit Charms

  • Discussed re-reviewing the current charms in the charm store to ensure accurate readmes, tests, functionality, rating, categories, and icons. The workflow was discussed for queues, and which charms to tackle first.

• Charm Development Tooling

  • Discussed gathering all the different charm development tools into one central package. These charm development tools include charm-tools, charmsupport, juju-gui,openstack-charm-helpers. Folks also discussed how the tools could be improved, and used as a singular set.

• Juju Framework Charm for Server Application Technologies

  • Discussed further building out of the Django, Rails, Node.js, and possibly Java.

• Improve Juju Documentation

  • Make a better user and charm developer experience for juju.ubuntu.com/docs. Discussed getting a permanent beta site going, methods to get documentation contributions. Hopefully a revamped docs will be in production in the next couple of weeks, and if not we’ll have a beta site very shortly (days).

• Juju Charm Testing

  • Currently jenkins.qu.u.c has graph testing showing reliable results. Marco will be landing integration soon (days), with a more formal testing framework to follow (weeks).
  • Some ideas discussed were to gate charm store commits on testing, showing testing status in the GUI, and pre-deployment testing. Test examples will be made available along with a charm testing school.

• Add User Feedback loops and Social Networking to Charm Store Charm Pages

  • Discussed making sure users have a method to give and receive feedback on a per charm basis. We currently have social networking (+1s, Likes, Tweets) in addition to downloads, quality rating, bug links, and testing status. Some ideas were to get clarification from design on showing social networking numbers, as well as a ‘leave feedback’ form.

• Juju GUI Development

  • Discussed development done, and upcoming work. Covered ideas such as design, bundles, diagnostics, user data, juju feature parity, maintenance and support.

• Improving QA for seeded server packages

  • Established three distinctive areas of testing, these are upstream test suites which typically run at build-time, integration tests via dep8 and service level testing which often requires multiple nodes and is conducted using juju.
  • We established that there is the regression test suite that can be included in many of the packages directly, with the requirement that we package some of the common ubuntu testing libraries.
  • Discussed some areas of standardisation for dep8 testing.

• Fastpath installer work for 13.10

  • Established what FPI is, and the processes which are part of it.
  • Fast Path installer will be delivered as a installable package in Ubuntu, most likely in python. The interface to it will we yaml formatted configuration.

• OpenStack Charm work for Saucy/Havana

  • Migrate all charms to be python based.
  • Consolidation into new charm-helpers nextgen library.
  • Complete SSL/HTTPS support into charms.
  • Integration of wiki and help documentation, upstream series aligned with upgrading notes.
  • Design around how proprietary+1 plugins will be integrated into core charms for Cinder and Quantum.

• Investigate alternatives to mysql

  • Agreed that the best course of action was to maintain mysql for this cycle, and try and support other flavours of mysql getting into Ubuntu via Debian.

• Ceph activities for Saucy

  • Dumpling release will be out in August (co-incides with FF for Saucy) so will be target for this release.
  • Lots of incremental improvements in efficiency and performance, full RESTful API for RADOS Gateway admin features, block device encryption for data at rest.
  • ceph-deploy (upstream cross platform deploy tooling) will be packaged.
  • Implementation of more automated testing during Saucy.

• HA Openstack charms V2

  • Reviewed the current state of HA support in Openstack charms. Percona has volunteered to charm their offering, allowing great coverage by their mysql HA variant for active/active clustering.
  • Work also on active/active and brokerless messaging options (ZeroMQ) and incremental improvements for service check monitoring in load balancers.
  • Cluster stack (Corosync/Pacemaker) to be reviewed and upgraded for Saucy in preparation for 14.04.

• MongoDB activities for Saucy

  • File Main inclusion report for Mongo to support Ceilometer and Juju use cases. Raise a Micro Release Exemption (MRE) to the techboard, as point releases are bug fix only.
  • Upstream armhf enablement patches. Re-sync with Debian. OpenSSL license exception.

• Virtualization Stack Work for Saucy

  • If debian libcgroup maintainer finds time, we’d like to merge cgroup-lite into libcgroup. For per-user configuration, first make it default-off optional, conditional on userns sysctl being enabled.
  • LXC work is going well on track to 14.04 (and lxc 1.0) roadmaps. For this cycle, we’d like to get user namespaces enabled in the saucy kernel with a new off-by-default sysctl controling unprivileged use, and complete the ability to create and start basic containers without privilege; add console, attach and snapshot to the API, complete the create API function, and convert all of the lxc-* programs to use the API; write a libvirt driver based upon the API, and a patch to enable testing it with openstack; write loopback and qcow2 block device drivers; Get the subuid (user namespace enablement) patches into the shadow package; discuss with the community the maintenance of stable trees; improve the API thread safety; and work our distro lxc tests into the upstream package (akin to how it is done in netcf).
  • In edk2, we want to contribute to the implementation of the ability to save and restore nvvars from the ovmf bios from qemu. We’ll fix the apparmor bug preventing the block device mounting in libvirt-lxc, which is blocking use of that feature by openstack.
  • We intend to merge libvirt at least at version 1.0.6, qemu at 1.5, and hopefully xen 4.3. We’ll follow up on citrix’ plans for xcp. The blueprint lists additional xen work planned. We’ll also look into default use of openvswitch bridges in libvirt.

Quality Assurance

• Core Apps

  • Autopilot testcases written for ubuntu core applications will be checked to ensure they pass before auto-landing updates in the ubuntu touch images.
  • The quality community team will help core application developers develop a suite of manual testcases for each ubuntu core application. These will be run as part of the verification process for the 1.0 stable release of each application.

• Testcases

  • Add testcases so all default desktop applications for each flavor are covered.
  • Expand and improve server testcases to allow more participation by those who might lack domain specific knowledge and/or hardware.

• Growth/Experience

  • Make available documentation more accessible by linking to it from the tools we use for testing, like the qatracker.
  • Continue holding testing ‘how-to’ and knowledge sharing sessions during UDW, UOW, as part of UGJ, and on ubuntu on air.
  • Add testing achievements to the ubuntu accomplishments project.

• Ubuntu Touch

  • Ubuntu Touch images will be smoke tested using the pending/current model already in use for other images. This ensures no image is published for general consumption that doesn’t pass a set of tests ensuring basic functionality of the image.
  • Current Ubuntu Touch autopilot tests for the core applications will be investigated for use as part of these smoke tests.
  • The concept of smoke test is going to be expanded to cover a no regression build.

• Autopilot

  • Autopilot 1.3 is now released and will be available in raring and saucy. No quantal support is planned. Precise support is being examined, but requires further investigation and backporting work.
  • Autopilot developers will now be available on #ubuntu-autopilot — no need to always ping thomi!

• Mir

  • Planned tests for stressing mir to ensure good behavior during stressed conditions for things like OOM, memory leaks and race conditions.
  • Stress tests targeted to be run as often as possible, but might be limited due to time constraints of wanting to run the tests over a longer period of time.

• UTAH

  • UTAH will be expanded to include automated upgrade testing capabilities. UTAH jobs will be created for bootstrapping base images, for performing upgrades, and running post-upgrade tests. The old auto-upgrade-testing tool can still be used by flavors if desired.

• Dashboard

  • Create high-level views of the state of quality in ubuntu by aggregating results of test runs. This will allow for ‘problem’ areas within ubuntu to be more easily identified and targetted for further testing or investigation by interested parties. You can follow this work on the QA dashboard here.

• Upstream

  • autopilot-gtk will now be maintained by the upstream QA team. Bug fixes and outstanding issues will be solved in order to allow for the autopilot desktop tests to run
  • Once running properly, the autopilot desktop tests will become a part of daily image testing
  • Continue development on umockdev to add support for more exotic networking tests (eg, 3G) and research sound testing

As ever, you can track progress on work items on status.ubuntu.com and we hope to see you at the next UDS in three months.

Colleague: "Look, how long do you think it will take to sort out those PC's? We could be at it all day!"
Me: "But once it's sorted they won't have anything to moan about?"
Colleague: "Yeah until one of em goes wrong."
Me: "But that should be easy and one failure is better than fifty odd in my book."

Since Jack was born my music has taken something of a back seat. Recently I got the itch to write a new song and here is my first metal tune since he was born. It is an instrumental named after his onesie with chimp feet. I wanted to enjoy writing a song that spins around a little bit without the need to make it radio-length. As such it weighs in at just under 7 1/2 minutes. Anyone want to make a music video for it.

I wrote and recorded this in my home studio and played the guitars and bass; drums are programmed this time around. Licensed as CC-BY-SA.

Download It Here

Recently there was yet another storm in a teacup that distracted us from creating and sharing Ubuntu and our flavors with others. I am not going to dive into the details of this particular incident…it has been exhaustively documented elsewhere…but at the heart of this case was a concern around the conduct in which some folks engaged around something they disagreed with. This is not the first time we have seen disappointing conduct in a debate, and I wanted to share some thoughts on this too.

In every community I have worked in I have tried to build an environment in which all view points that challenge decisions or decision makers are welcome with the requirement that they are built on a platform of respectful discourse; this is the essence of our Code Of Conduct. Within the context of an Open Source community we also encourage this engagement around differences to be expressed as solutions with a focus on solving problems; this helps us to be productive and move the project forward. This is why we have such a strong emphasis on blueprints, specs, bugs, and other ways of expressing issues and exploring solutions.

Within the context of this most recent issue I saw three problems (problems I have seen present in other similar arguments too):

1. Irrespective of the voracity or content of an opinion we must never forget to be respectful and polite in the way we express and engage with others, irrespective of whether you are a volunteer, Canonical employee, or otherwise. Respect must always be present in our discourse, irrespective of the content of our opinions; without it we become a barbaric people and lose the magic that brought this wonderful set of minds together in the first place. There is simply no excuse for rudeness, and inflammatory FUD that has no evidence to back it up other than presumed ill-intent serves nothing but to demotive folks and ratchet up the flames, as opposed to resolve the issue and make things better.
2. Trust needs to be earned, but trust should always be built within the wider context of a set of contributions and conduct. Unfortunately some folks consider decisions they disagree with to be a basis for (a) entering into a paranoid debate about the “real reason” the individual or company made that decision (and typically not believing the rationale provided by said decision-maker) and (b) seemingly forgetting about all the other positive contributions that the person or company has contributed. I can assure you there is no nefarious scheme at place at Canonical; our goals are well known in the community. If I felt Canonical was fundamentally trying to demote and shut the community out, I wouldn’t work here; I have no interest in working for a company that doesn’t understand the value of community, and I am not worried about finding suitable employment elsewhere. I work at Canonical because I believe our goals with Ubuntu are just and the company’s commitment to our community is sincere.
3. Ubuntu is not a consensus-based community. Consensus communities rarely work, and I am not aware of any Open Source project that bases their work on wider consensus in the community. It would be impossible and impractical to notify our community of every decision we make, let alone try to base a decision on a majority view, but we do try to ensure that major changes are communicated to our leaders first (this is something we have been driving improvements in recently). We always need to find the right balance between transparency and JFDI, and sometimes the balance isnt’t quite there, but that does not mean there is some kind of illuminati-ish scheme going on behind the scenes.

Ubuntu is a community filled with passionate people, and I love that we have folks who are critical of our direction and decisions. If everyone agreed with what we are doing, we would not always make the right decisions, and our diversity is what makes Ubuntu and our flavors such a great place to participate.

As I said at the beginning of this post, it is important that all viewpoints are welcome, but we have to get the tone and conduct of some of these debates under control. The sheer level of sensationalist and confrontational language that is often in place in these disagreements doesn’t serve anyone but hungry journalists looking for page hits.

Now, I am not suggesting here that anyone should change any of their viewpoints. If you vehemently disagree with an aspect of what we are doing in Ubuntu or at Canonical, that is fine and of course, welcome. What I am appealing to everyone though is to treat others like you wish to be treated, with respect and dignity, and lets keep the sensationalism out of our community and focus on what we do best…building a world-class Free Software platform and its rich ecosystem of flavors.

As many of you will know, our goal is to get the Ubuntu phone in a state where it can be used on a daily basis for testing, and importantly, finding bugs, UI issues, and other details that help us to refine the overall Ubuntu Touch experience. Progress is on-track for the end of May.

I decided to start dogfooding a little early (please remember, we are shooting for the beginning of July to be broadly in shape for dogfooding, so if you try, don’t expect things to be ready right now), so today I put my SIM card in my Galaxy Nexus with Ubuntu Touch and things are working pretty well so far. It seems that my data is no longer getting wiped on image updates, which helps testing significantly, so I am regularly upgrading with the daily images.

As ever, if you decide to test, you are doing so at your own risk…don’t be surprised to see bugs, crashes, and potential data loss (although I have not seen any data loss so far).

Some notes about my experience dogfooding:

• Making and recieving phone calls works well. I am using T-Mobile as my network.
• Sending and recieving texts works well too. Messages appear chronologically.
• Contact syncing is not in place but Sergio blogged about how to sync your contacts from Google. This has made my phone infinitely more useful and rather nicely, it pulls in the avatars too so I can see who is calling me.
• Browsing and connecting to wireless networks works well.
• The browser works well overall, although currently requires wifi (3G browsing coming soon).
• Camera works well (for still photos, video not implemented yet) and I can browse my pictures in the gallery.
• Many of the community-written core apps are present and working. Calendar lets me save and browse calendar events (although syncing with a calendar service is not there yet). Weather shows me the weather for my area right now and a week long forcast. Calculator is working and largely feature-complete. Other core apps are on their way to the daily image soon.
• Overall the core Unity UI is working well. I can search for apps, load them, quit them, multi-tasting works well, and the indicators work (for adjusting volume etc).

The primary blockers in my way right now for normal use out and about are:

• The screen does not auto shut-off. This means if the screen gets turned on in my pocket it never turns off and the battery dies.
• Speakerphone not wired into the UI yet.
• Can’t set the time on the phone yet. Also, the alarm feature in the clock doesn’t work; I need this to get me up in the morning.
• Not so much a blocker, but the phone is still filled with example material and contacts. They need to be removed.

All of these are on the TODO list for completion by the end of the month.

I have been filing bugs for a bunch of the issues I am seeing on a day to day basis and the team are working hard to hit the end of May goal. Overall progress is looking good.

Although I have been using the daily images for quite some time on a phone without a SIM card, using as an actual phone is even more motivating than before. I can feel the phone coming together and when we get many of these issues fixed, it is going to deliver a far superior experience than the Android phone I was using before.

Customer: "Can you quote me for two HP DC7700 and the other bits we discussed?"
Me: "Sure no problem, the 7700's are £145.00 each by the way."
Customer: "Ooh that price is really good, I might take nine instead. How much for nine, is there a discount?"

Hang on a sec, because it's such a good price you want seven extra but you want them even cheaper still? tell you what, just buy the two at the fair price I'm selling them at.

A while back I started a project called the Ubuntu Advocacy Kit. The goal is simple: create a single downloadable kit that provides all the information and materials you need to go out and help advocate Ubuntu and our flavors to others. The project lives here on Launchpad and is available in this daily PPA. If you want to see the kit in action just run:

sudo add-apt-repository ppa:uak-admins/uak sudo apt-get update sudo apt-get install uak-en

Now open the dash and search for “advocacy”. Click the icon to see the kit load in your browser.

We discussed the UAK this week at UDS and I want to get the kit to 1.0 level of completeness. This doesn’t require a huge amount of work, just getting a core set of content written up in a concise, simple, but detailed fashion. I want to complete this work and then get the kit up on loco.ubuntu.com as something people can download to get started advocating Ubuntu and our flavors.

I have created a blueprint to track this work and I am stubbing out a bunch of pages in the kit for pages that I think we will need as part of a 1.0 release.

And why are you telling me this?

Well, I am looking for help.

If you enjoy writing and have a knowledge of good quality advocacy, I would like to invite you to write some content. If you can just reply to this post in the comments (or anywhere else I tend to look, such as email or IRC), we coordinate who works on what and I will update the blueprint where appropriate.

Thanks for reading!

Recently the Technical Board made a decision to sunset Brainstorm, the site we have been using for some time to capture a list of what folks would like to see fixed and improved in Ubuntu. Although the site has been in operation for quite some time, it had fallen into something of a state of disrepair. Not only was it looking rather decrepit and old, but the ideas highlighted there were not curated and rendered into the Ubuntu development process. Some time ago the Technical Board took a work item to try to solve this problem by regularly curating the most popular items in brainstorm with a commentary around technical feasibility, but the members of the TB unfortunately didn’t have time to fulfill this. As such, brainstorm turned into a big list of random ideas, ranging from the sublime to the ridiculous, and largely ignored by the Ubuntu development process.

Now, some folks have mused on the decision to sunset brainstorm and wondered if this is somehow a reflection on our community and our openness to ideas. I don’t think this is the case. While it is always important to build an environment where ideas are openly discussed and debated, ideas are free and relatively simply to come by, and the real challenge is converting that awesome vision in your head into something we can see and touch and deliver to others; this is not quite so free and simple. While Brainstorm provided a great place to capture the ideas, and we had no shortage of them, the challenge was connecting brainstorm to the people who were happy and willing to perform the work, and it didn’t really serve this purpose very well.

There were two problems with this. Firstly, picking up other people’s popular ideas is not how Open Source traditionally works. Open Source is built on a philosophy of scratching your own itch, traditionally fueled by programmers fixing their annoyances and building features and applications they want. Now, this is not to say a non-programmer can’t rally the community around their idea and build momentum around an implementation, but doing this requires significantly more effort than a fire and forget submission into brainstorm. In other words, just because an idea is popular doesn’t necessarily mean it is interesting enough for a developer to want to implement it. Secondly, brainstorm started to garner an unrealistic social expectation that popular ideas would be automatically added to the TODO list of prominent Ubuntu developers, which was never the case.

Today at UDS we had a discussion about these deficiencies in brainstorm in traversing the chasm between idea and implementation and Randall Ross had an interesting idea. With brainstorm retired we should re-focus the brainstorm URL and provide some guidance for tips and tricks for how to take an idea and rally support around it to develop an implementation. As an example, over the years I have discovered that taking an idea and building a well formed spec with detailed UI mock-ups and architectural diagrams, a detailed blueprint, regular meetings, and burndown charts, all significantly help to taking ideas from fiction to fandom. Equipping our community with the skills and tools to bring these ideas to fruition is a better use of our time.

So, the TL;DR of all of this is…brainstorm was a great idea at the time, but it didn’t effectively drive the most popular ideas in our community to fruition and delivery in Ubuntu. We want to help provide guidance and best practice to help our community be more successful in converting their ideas into development plans and getting people interested in participating.

Hot on the heels of my last post showing Unity 8 running on Mir on a Macbook Pro Retina, there were some folks who were curious about how well Unity and Mir work on a phone.

Well, thanks to your friend and mine, Kevin Gunn, you can see a video of Unity 8 on Mir running on a Galaxy Nexus (which is by no means a super-powerful smartphone these days):

Can’t see the video? See it here!

Again, just to emphasize, this has not been through a round of performance optimizations, so you can expect additional performance improvements in the future, but I think this demonstrates that we are heading in the right direction.

If you are interested in participating in Mir development, click here and if you are interested in participating in Unity 8, click here.

Recently the Mir and Unity Next teams got Unity 8 up and running on Mir. Now, this work is still very early in development and neither Mir nor Unity Next are finished yet, but I reached out to Michael Zanetti, who is on the team, and asked him to put together a short video demo to show the progress of this work. This demo shows the phone/tablet part of the Unity 8 codebase; the final desktop version will come later.

Here is is:

Can’t see the video? Click here!

As you can see, impressive progress is being made; this demo is running on a MacBook Pro Retina utilizing the full resolution of 2880×1800 pixels and using Intel HD 4400 graphics. The performance is already looking great, and the team haven’t done a deep dive into performance optimization yet.

If you are interested in participating in Mir development, click here and if you are interested in participating in Unity 8, click here.

As a pretty simple-minded person, I am a big fan of simplicity. The world is filled with too much complexity and too much detail. Many often feel the detail is necessary for particular outcomes or to solve particular problems. The lesson I have learned as I have gotten older though is that while the skill is in matching the level of detail to the mind of the observer, the real elegance is in delivering the same level of detail but in a way that feels simpler than expected to the observer. This results in delightful experiences.

Ross Gardler recently quoted Einstein who said “everything should be made as simple as possible, but not simpler“. This so beautifully summarizes my view of the world; life should be as simple as we can make it, but we should not compromise in our goals merely to make things simple. In other words, if we can boil our projects, processes, interfaces, and ideas down into simpler parts that still let us be productive, they become more enjoyable to engage with and thus more successful. Of course, making complex things simple is…complex. It is though, worthwhile, and for many (myself included), a fun challenge. I am sure I am not alone.

As we step into our Ubuntu Developer Summit this week I would like to encourage everyone to think about ways in which we can simplify all aspects of how create and deliver Ubuntu to others as a means to further the project and experience. This doesn’t just apply to user interface design though. How do we make our teams easier to navigate and participate in? How do we make it easier to create your first app, charm, bug fix, translation, document, mailing list post, question, answer, or otherwise? If we can make in-roads this week in simplicity, I am confident it will continue the bold stride Ubuntu is making into the future of devices and the cloud.

Just a quick note to remind everyone that our next Ubuntu Developer Summit is taking place this week on Tuesday, Wednesday and Thursday, and is open and available to everyone to participate. This is the event where we get together to discuss, debate, and plan the next three months of work.

The event takes place online from 2pm – 8pm UTC. All sessions will run using a combination of Google+ streaming video hangouts and IRC, and you can see the full schedule on summit.ubuntu.com. Consequently, for those who cannot attend or might miss certain sessions, all sessions will be available pre-recorded from the session pages when the session is complete.

The event kicks off on Tuesday at 2pm with our keynote. We hope to see you there!

Last week I traveled to Oakland to spend a week with my colleagues at Canonical for the Client Sprint. The aim of the sprint was to ensure the many different teams working on Ubuntu Touch at Canonical are in sync and working as efficiently as possible. This largely involves ensuring that the management teams are planning their work effectively, and that everyone is singing from the same hymn sheet.

To provide a little context, at Canonical we are working consistently to deliver a 1.0 Ubuntu Touch platform that is ready for October so it can then be delivered to customers for deployment on handsets in Q1/Q2 2014. This involves a wide variety of design, engineering, and service-delivery projects that currently involves 15 engineering teams, 5 design teams, and 5 services teams, totaling 150+ people. The aim of the sprint was to ensure these 150+ folks are aligned.

Now, some cynical people (who I suspect may need more hugs) think that the sprint is merely a Canonical-only UDS where we make a bunch of private decisions by explicitly excluding the community. Sorry, drama fans, this is not true. We spend our time discussing and managing Canonical staff and resources, talking about product review documents, staff assignments, hardware/IS requirements, reporting structures, stakeholder and customer requirements, and wading through endless spreadsheets to track all of this. We don’t do this at UDS as UDS is not a good event for this kind of team alignment work as we are all spread across multiple tracks (and most of our community would have little interest in these team discussions anyway), hence we have always had sprints to do this.

The sprint had a very definitive format. Every team has a defined set of responsibilities and projects and each team lead prepared a summary of their work, achievements, and blockers. As an example, one project my team has been working on is the skunkworks and core apps projects, and wider app development community growth. I gave a presentation that summarized this work and it provided an opportunity to update the wider team and identify areas in which we can work more efficiently (e.g. one outcome was opening up a more regular communication between myself and the head of the SDK team).

The good news is that things are running really well. The teams were well prepared, great progress is being made on the road to October, and any inter-team and inter-project issues that we did find were quickly and efficiently resolved. For such a large project with so many inter-connecting parts I was pleasantly surprised with just how coordinated everyone seems to be, and I want to thank the many engineering, design, and services managers and leads for their (often understated) leadership and planning. It is complex to coordinate so many moving parts when everyone works in the same office, let alone for such a widely distributed company working from home with so many different timezones.

Of course, there were many topics and projects discussed at the sprint, but there was one topic that resonated throughout the week: getting Ubuntu Touch into a form in which our community can start dog-fooding as soon as possible. In other words, right now you can download the daily Ubuntu Touch images, but you can’t really use it as your main phone; it still comes with a bunch of dummy data, some radio functions don’t work, and there is no way of saving data when you re-flash the device. In the next few months the teams agreed to expedite their work to make the Ubuntu Touch images ready so we can use them as our daily devices, thus opening more opportunities for testing, feedback, functionality edge cases, and more.

I have another sprint coming up this week (the Cloud sprint), but I have asked a number of people who joined the sprint to blog about their progress and updates. Keep your eyes peeled for more.

Arbitrary tweets made by TheGingerDog (i.e. David Goodwin) up to 01 May 2013

• RT @funkatron: I thought this was pretty interesting on the cognitive dissonance tip t.co/t0hWaG45kx (2013/04/28)
• Iron man 3 had some flying robot things in it. And a few explosions. And a few references to The Avengers. Good film. (2013/04/27)
• Jacked up. t.co/ysHOg3min7 (2013/04/26)
• RT @AndrewBate: @WooWebUk We’ve a vacancy at Talis for a Tech Lead – any chance of an RT? t.co/gqdppuz0ue (2013/04/26)
• RT @Nick_Greenhill: Ideally would also have expereince with SVN/Git, Mobile and responsive web, extra points for Node.js. Direct applicatio… (2013/04/26)
• RT @Nick_Greenhill: Right, I need PHP with experience in Yii or other MVC framework, Javascript and Jquery, MySQL, HTML, CSS (cont..) (2013/04/26)
• Apparently… I've given blood 10 times and now have a badge to prove it. (2013/04/26)
• RT @harrybr: SO USEFUL for dummy content in prototypes: in a google spreadsheet, create a series of two items, hold Alt & drag! http://… (2013/04/25)
• RT @PeteWilliams: @harrybr That is actual, bonafide, fucking awesome. Amazing what it works with too: t.co/BbBa7Ziqsq (2013/04/25)
• "You seem bored tonight …. Aren't you going running?" #hinthint #hintTaken (2013/04/24, Bromsgrove, Worcestershire)
• RT @yorba_org: 55 hours to go and we're seeing a huge surge in donations! Can you be a part of the last-minute push? t.co/THrjdv8x2b (2013/04/23)
• RT @Port80Events: Port80 2013 – web conference, Newport – 10th May – the running order t.co/YZ5nNuL5Of <– hot off the press (ple… (2013/04/22)
• RT @kelsojonesltd: Are you a #PHPDeveloper based near #Leicestershire? Looking for a new role? click here for more information t.co/… (2013/04/22)
• My car is faster than a Ferrari! (2013/04/22)
• The average learner's swimming pool is 10% spit, 10% wee, 10% vomit, 50% chlorine and 20% water. (cc @madeupstats ). (2013/04/21, Bromsgrove, Worcestershire)
• RT @alexmace: CONTINUE TESTING t.co/RGtquZSfvz (2013/04/20)
• Just read some interesting javascript form validation code for a postcode. Shame it's case sensitive. #fail (2013/04/18)
• I need to write a presentation. (2013/04/18)
• RT @bytemark: "If you run a hosting company… and want to help the industry, support Geary" – Bytemark Hosting MD – t.co/rr0RAJC … (2013/04/18)
• RT @ZombiesRunGame: We answer somebquestions about Zombies, Run! 2 in our latest blog post, including Season 1 availability – t.c … (2013/04/17)
• RT @anya_goodwin: Can't be bothered to wake up – so I'll cry in my sleep to make daddy feel useful. He needs something to do after all. (2013/04/16)
• RT @WooWebUk: Geek Night 2 is Thursday, 7:30pm at @TheHiveWorcs. Room for more speakers! Got something web related you can talk about fo … (2013/04/15)
• RT @ZombiesRunGame: It’s less than 24 hours until we raise the gates on Zombies, Run! 2 – are you all ready to run? (2013/04/15)
• RT @carlfish: IT security in a nutshell. t.co/Owih8Xzw0y (2013/04/15)
• composer++ ( t.co/0ykJCj1PyO etc ) #php (2013/04/15)
• RT @phalconphp: How to lose weight
  in the browser? t.co/ZFIrGibt2w (2013/04/14)
• RT @AnthonySterling: +1 “@craigmarvelley: Fab tutorial on how to use Composer from @daylerees t.co/IZUh2bAnxb” (2013/04/14)
• RT @dogster24: Catch the thieving scumbags , please rt this everyone t.co/CvfdkNXeIi (2013/04/14)
• RT @RFU_RDO:

So a customer came to see me to discuss yet more changes they wanted to make.

Customer: "See here on the final check out it's saying Tax 7%?"
Me: "So who changed the values?"
Customer: "I, I don't think we have?"
Me: "OK lets go Taxes--->Tax rates, change to UK 20%"
Customer: "Ooh was it that easy?"
Me: "Yep, but I'm still billing you for it."
Customer: "But? But?"
Me: "Hey, I knew how to do it and you didn't that's why you pay me."

Ker Ching

On Thursday, 18 April, I sat and passed the RCF Intermediate exam. After a delay due to a problem on the Ofcom website, I finally got the call sign 2E0RJW on Friday 26th April.

So I am now allowed to work on all the amateur bands at powers up to 50W.

Next stage, the Advanced exam.

I have a theory (I know, I am full of them). Like most of you, as I have gotten older I have also tried to improve as a person. I am not just talking about being better at what I do with my career and hobbies, but I want to be a genuinely good person across the board; a good husband, father, son, friend, colleague, and dude who you bump your shopping cart into when buying milk. My theory is that people fundamentally improve by (a) making mistakes and (b) understanding and learning from those mistakes to not only prevent making the mistake again, but to also uncover the cause and effect of why the mistake was made, thus improving your life.

Now, the (probably illogical) logical continuation of my theory is that to make improvements (a) you need to make more mistakes (which opens up the opportunity for learning), and (b) you need to develop CSI-like capabilities in assessing those mistakes and their root causes. Continuing the theme, if we can figure out ways to identify ways of triggering making more mistakes in a way that doesn’t get you arrested and we can identify ways to help us understand why we screw up the way we do, we should have a golden ticket for rocking our lives. Incidentally, this theory was boiled in my head while driving out to pick up Thai food on Saturday night, so this is no Einstein’s Theory Of Relativity in terms of completeness.

While I am rather thin on the ground in terms of what is the next logical part of my theory, I suspect that the way in which we invite more none-life-threatening mistakes is to break out of our molds and take more risks; if we never take chances, we lower the opportunity for risk and mistakes, but also lower the opportunity for learning. Likewise, for the latter understanding our mistakes part I suspect the key is not figuring out ways to prevent the mistake (“I got angry and shouted at my dog today so I will try to keep my cool”) but more about understanding the cause of the mistake (“I am stressed from work and bringing that stress home and taking it out on people and animals”). Much as I love dogs, the goal here is not to stop shouting at the dog but to repair the root cause. So I ask you, dear friends, does my theory wash with you, and if so, how can we increase the number of mistakes and the quality of our self-assessment of those mistakes?

Ubuntu 13.04, the Raring Ringtail, was released today. Go and download it for Desktop, Server, Cloud, and for our Chinese friends, download Ubuntu Kylin. You can find all the details of what is new in Ubuntu 13.04 on www.ubuntu.com.

Ubuntu 13.04 is a fantastic release, and I just want to offer thanks to the many people around the world in our community who helped make it happen. Folks such as developers, app/charm authors, designers, testers, triagers, translators, sys-admins, support providers, governors, docs writers, advocates, and more, all contributed their brick in the wall to delivering Ubuntu 13.04 across Desktop, Server, and Cloud, and continuing to bring freedom and elegance in technology to more people. But this is only part of the story, as behind the scenes, but in full public view, we are continuing to evolve Ubuntu towards our convergence goals. This will be a common theme as we march forward to Ubuntu 13.10, the Saucy Salamander.

I know many of us are tired after a hectic release schedule, so take some time to enjoy the release, get together with other Ubuntu friends, and celebrate Ubuntu 13.04! I will certainly be blowing the froth off a few cold ones tonight.

Ubuntu is on an exciting journey, a journey of convergence. Our goal is to build a convergent Operating System that brings a uniformity of technology and experience across phones, tablets, desktops, and televisions, and smoothing the lines between those devices in terms of interoperability and access to content. It is a bold vision, but Ubuntu has a strong reputation both in terms of our heritage in the desktop, server, and cloud, and with our passionate and capable community. I just wanted to provide some updates on work that is going on in delivering this vision.

There has been significant work going on in building Ubuntu Touch (the overall name for this convergent platform). The team have marked October in their calendars as the goal to have most of the primary components in the Ubuntu Touch code-base complete so we can deliver a fully converged system in Ubuntu 14.04. The Unity team have been working to centralize the different form factors into Unity Next, which you can play with now (weekly updates on progress coming soon here), the Mir team are making good progress in getting Mir ready for deployment on handsets with a technical preview on the desktop in 13.10 (see the weekly updates), and the Ubuntu SDK team are working towards delivering a beta in the next few months. We have also been working with our community to build the 11 core apps (of which three them are already shipping in the Ubuntu Touch daily development image), the Ubuntu Touch code-base has been ported by our community to and working on 40 handsets, with 25 handsets in progress, and across 19 different brands (of which the 4800+ posts in the XDA Ubuntu Touch forum has helped drive this work), and our app developer community has already grown to 1650 members on Google+ with a huge variety of apps in development, many of which we are pulling together in a PPA. We have also been working to automate the app submission process with a series of AppArmour sand-boxing improvements and tooling changes, we have an eight part tutorial series for writing an app from scratch, and have multiple training events and an Ubuntu App Showdown contest planned. On the business side we have seen tremendous interest from handset manufacturers and carriers, and the business team are in a marathon set of meetings across the world moving the discussions forward.

There is a lot to do, but we have an awesome team and community committed to the opportunity that lays before us. If we stay focused, stay on the ball, and take an organized and pro-active approach to problem solving, we could bring real technological change to the world with Ubuntu delivered via the very devices that form the fabric of most people’s lives. Let’s do it.

Me: "Why cant I ssh in?"
Me: "Helps if you use 10.165 and not 10.65 you cretin!"

Me: "Why is it not detecting index.php?"
Me: "It helps if you put the site in /var/www/ and don't put it in /root/ you amoebae!"