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.

Read more

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.

Read more

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.

Read more

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!

Read more

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.

Read more

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.

Read more

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.

Read more

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.

Read more

If you are interested in either OpenStack or MySQL (or both) then you need to know about 2 meetups running the evening of May 23rd in London.

The London OpenStack meetup.

This is the 3rd meeting to take place and promises to be a good one with 3 talks planned so far:

* Software defined networking and OpenStack – VMWare Nicera’s Andrew Kennedy
* OpenStack Summit Overview – Rackspace’s Kevin Jackson
* An introduction to the Heat API – Red Hat’s Steven Hardy

For a 4th talk we are looking at a customer example – watch this space.

To come along please register at:

http://www.meetup.com/Openstack-London/

The MySQL Meetup.

This group hasn’t met for quite some time but MySQL remains as popular as ever and new developments with MariaDB mean the group has plenty to catch up on. There 2 talks planned so far:

* HP’s database as a service – HP’s Andrew Hutching

* ‘Whatever he wants to talk about’ – MySQL and MariaDB founder Monty Widenius.

 

With David Axmark also in attendance it could be one of the most significant MySQL meetings in London ever. Not one to miss if you are interested in MySQL, MariaDB or related technologies

MySQL meetups are managed in Facebook – please register to attend here:

http://www.meetup.com/The-London-MySQL-Meetup-Group/events/110243482/

 

Of course given the events are running in rooms next to each other you are welcome to register for both and switch between them based on the schedule. We hope to see you there!

Read more

Packages

I quite like the current status of Qt 5 in Debian and Ubuntu (the links are to the qtbase packages, there are ca. 15 other modules as well). Despite Qt 5 being bleeding edge and Ubuntu having had the need to use it before even the first stable release came out in December, the co-operation with Debian has gone well. Debian is now having the first Qt 5 uploads done to experimental and later on to unstable. My work contributed to pkg-kde git on the modules has been welcomed, and even though more work has been done there by others, there haven't been drastic changes that would cause too big transition problems on the Ubuntu side. It has of course helped to ask others what they want, like the whole usage of qtchooser. Now with Qt 5.0.2 I've been able to mostly re-sync all newer changes / fixes to my packaging from Debian to Ubuntu and vice versa.

There will remain some delta, as pkg-kde plans to ask for a complete transition to qtchooser so that all Qt using packages would declare the Qt version either by QT_SELECT environment variable (preferable) or a package dependency (qt5-default or qt4-default). As a temporary change related to that, Debian will have a debhelper modification that defaults QT_SELECT to qt4 for the duration of the transition. Meanwhile, Ubuntu already shipped the 13.04 release with Qt 5, and a shortcut was taken there instead to prevent any Qt 4 package breakage. However, after the transition period in Debian is over, that small delta can again be removed.

I will also need to continue pushing any useful packaging I do to Debian. I pushed qtimageformats and qtdoc last week, but I know I'm still behind with some "possibly interesting" git snapshot modules like qtsensors and qtpim.

Patches

More delta exists in the form of multiple patches related to the recent Ubuntu Touch efforts. I do not think they are of immediate interest to Debian – let's start packaging Qt 5 apps to Debian first. However, about all of those patches have already been upstreamed to be part of Qt 5.1 or Qt 5.2, or will be later on. Some already were for 5.0.2.

A couple of months ago Ubuntu did have some patches hanging around with no clear author information. This was a result of the heated preparation for the Ubuntu Touch launches, and the fact that patches flew (too) quickly in place into various PPA:s. I started hunting down the authors, and the situation turned out to be better than I thought. About half of the patches were already upstreamed, and work on properly upstreaming the other ones was swiftly started after my initial contact. Proper DEP3 fields do help understanding the overall situation. There are now 10 Canonical individuals in the upstream group of contributors, and in the last week's sprint it turned out more people will be joining them to upstream their future patches.

Nowadays about all the requests I get for including patches from developers are stuff that was already upstreamed, like the XEmbed support in qtbase. This is how it should be.

One big patch still being Ubuntu only is the Unity appmenu support. There was a temporary solution for 13.04 that forward-ported the Qt 4 way of doing it. This will be however removed from the first 13.10 ('saucy') upload, as it's not upstreamable (the old way of supporting Unity appmenus was deliberately dropped from Qt 5). A re-implementation via QPA plugin support is on its way, but it may be that the development version users will be without appmenu support for some duration. Another big patch is related to qtwebkit's device pixel ratio, which will need to be fixed. Apart from these two areas of work that need to be followed through, patches situation is quite nice as mentioned.

Conclusion

Free software will do world domination, and I'm happy to be part of it.

Read more

Congrats and thanks to everyone,

Debian 7.0 Wheezy released

Updating my trusty orion5x box as we speak. No better way to spend a (jetlagged) Sunday.

Read more

Recently Microsoft Open Technologies celebrated their one year anniversary. I just wanted to offer my congratulations on this important milestone.

Now, it could be tempting for some of you to become a little snitty about Microsoft wanting to engage more openly with people, but I believe that this project (as well as the OuterCurve Foundation; a different but similarly themed entity) should be celebrated. These are important steps in Microsoft evolving into a more open future, and folks such as Gianugo Rabellino from Microsoft Open Technologies and Paula Hunter and Stephen Walli from the OuterCurve Foundation are doing wonderful work in treading these careful steps forward. All three of these folks have been tremendously supportive of Open Source, community (including sponsoring the Community Leadership Summit multiple times), and demonstrate a real commitment to delivering those values in a historically proprietary culture. I can imagine that this is not particularly easy work, and I commend them for their commitment, and Microsoft for their evolution as a company.

Open Source has had a profound impact on the world, and for a company with such a philosophically different history to commit staff and resources to exploring a more open future, well, I think this is a fantastic step forward for Microsoft, Open Source, and wider interoperability.

The Microsoft Open Technologies team will be celebrating on Thursday in Silicon Valley with their anniversary party. Be sure to head over there; unfortunately I am unable to join due to another commitment.

Congratulations, Microsoft Open Technologies!

Read more

I just wanted to talk about a busy week of community management and leadership related content I will be involved in in July 2013 in Portland, Oregon.

Community Leadership Summit 2013

The Community Leadership Summit is the primary annual event that brings together community leaders, organizers and managers and the projects and organizations that are interested in growing and empowering a strong community. The event pulls together the leading minds in community management, relations and online collaboration to discuss, debate and continue to refine the art of building an effective and capable community.

The Community Leadership Summit 2013 takes place at the Oregon Convention Center in Portland, Oregon on 20th – 21st July 2013, which is rather conveniently the weekend before OSCON.

At the heart of Community Leadership Summit 2013 is an open unconference-style event in which everyone who attends is welcome to lead and contribute sessions on any topic that is relevant. These sessions are very much discussion sessions: the participants can interact directly, offer thoughts and experience, and share ideas and questions. These unconference sessions are also augmented with a series of presentations from leaders in the field, panel debates and networking opportunities.

I can’t quite believe that this is the fifth anniversary of the Community Leadership Summit, and I am determined to make this the very best year yet! We already have an awesome list of pre-registered attendees, and this is shaping up to be yet another fantastic example of the primary place for community managers and leaders to get together to discuss, share, and learn best practice.

The event is completely free to attend, you just need to register first. I hope to see you there!

Community Management Training at OSCON

Speaking of OSCON, which takes place the week after the Community Leadership Summit 2013, I am also delighted to announce that I will be running my very first community management training class.

As some of you will know, I wrote The Art of Community published by O’Reilly (now in its second edition), which has rather fortunately become the best-selling book on community management and leadership.

For some time now I have wanted to deliver a training class that takes many of the concepts of the book, but extends them with detailed problem solving discussions, workshops, Q+A sessions, and more to provide an intense, detail-rich class about how to manage and lead communities, be them small and local or large and global.

On Monday 22nd July 2013, the day after the Community Management Summit 2013, I will be delivering this one day community management training class.

Topics in the class will include:

• Welcome and Introductions
  • Discussing how the class will work, student introductions, and facilities information.
• The Core Mechanics Of Community
  • Read/write communities.
  • Understanding the social dynamics.
  • Building retention and generational growth.
• Planning Your Community
  • Understanding where to focus community management.
  • Gathering stakeholder and community requirements.
• Building a Strategic Plan
  • The importance of a crisply defined strategic plan.
  • Structuring and documenting goals and objectives.
  • Delving down to the work item level.
• Building Collaborative Workflow
  • Understanding the collaborative needs of your community.
  • Building effective communication channels.
  • Determining infrastructure and tooling needs and how to resource them.
• Defining Community Governance
  • The role of governance.
  • Governance styles: dictatorship, delegated leadership, and enlightened dictatorship.
  • Assessing the governance needs for your community.
  • Building, codifying and documenting your governance structure.
  • Growing effective leadership in your community.
• Marketing, Advocacy, Promotion, and Social Media
  • Assessing marketing, advocacy and promotional needs.
  • Building a buzz cycle.
  • Using social media effectively.
  • Tracking publicity work and re-aligning for efficiency.
• Measuring Your Community
  • Knowing what to measure.
  • Defining useful growth and health metrics.
  • Understanding to how to read and react to metrics to provide more focused strategy.
• Tracking and Measuring Community Management
  • The importance of building credibility from good work.
  • Planning for different visibility needs: stakeholders, the community, and your team.
  • Tracking projects, using burndown charts, and reacting to project changes.
  • Tracking growth and decline.
  • Tracking community health and building a network

Find out more about and book your seat in the class by clicking here. Space is limited, so be sure to reserve your seat as soon as possible!

Burnout and Bickering: a Community Manager’s Guide to Conflict

I am also pleased to announce that I will be presenting a brand new presentation at OSCON on Wednesday 24th July 2013 at 2.30pm in D137.

The talk is entitled Burnout and Bickering: a Community Manager’s Guide to Conflict, and here is the description from the talk page

One of the most challenging aspects of growing community is managing conflict and burnout. While we often see the effects of conflict, getting to the heart of the issue is often more challenging.

In this new presentation from Jono Bacon, the Ubuntu Community Manager and author of The Art of Community, he presents a comprehensive guide to conflict and its many different causes.

The presentation explores how to identify these different causes (such as stress, personality differences, language/age/cultural barriers, and more), how to identify when problems are happening in a scalable manner, and how to resolve conflict in a progressive and repeatable way.

Bacon will also cover preventative measures to reduce the potential for both conflict, stress, and burnout, and wrap the content in a set of practical tools you can use in your own community.

All of this will be delivered in Bacon’s amusing anecdote and story filled style, delivering practical recommendations and techniques in a fun and contextual presentation.

I am excited about this presentation. As some of you will know, I have talked before about burnout and managing stress and conflict in communities, and this presentation provides extensive coverage of the topic. I am looking forward to presenting this at OSCON.

See more about the talk by clicking here.

As you can see, quite a week for community management and leadership! I hope to see you there!

Read more

I’ve blogged three times now, here, here and here, highlighting some of the apps being written with the Ubuntu SDK.  Well after covering 44 of them, and more already popping up since yesterday’s article, we’ve decided that we need to start getting these into the Ubuntu Touch Preview images so that people can try them out on supported devices, give the developers real-use feedback and bug reports, and generally promote the amazing work being done by our community of app developers.

The Collection

So Alan Pope (popey) and I have kicked off what we’re calling the App Collection, which are apps being developed outside of the scope of our Core Apps project, but that we still want to support, promote, and  guide through the process of getting them ready for deployment to Ubuntu devices.  This means we’re going to commit to helping developers get their apps packaged, and we’re going to be uploading them to a new PPA specifically for these apps.

The Apps

We’re starting out by collecting a list of known apps, with information about where to find their source code, the status of packaging for the app, and finally whether they are available in the PPA or not.  I seeded the list with the apps I’ve been blogging about, but it’s open to anybody who has an app, or knows about an app, to add it to this list.

Apps should be in a usable state before adding them to the list, and should perform a function that might be of interest to a user or tester.  Hello World apps are great for learning, but it’s not really something that you want to promote to users.

Packaging

You don’t have to know about Debian packaging to get your app in our PPA, we’re going to help you bootstrap and debug your package.  Our goal is to provide the minimal amount of packaging necessary for your app to be installable, on the desktop or on devices, and work properly.  Of course, if you can provide packaging for your app, that will greatly speed up the process of getting it into the PPA.

We would also welcome any help from packagers. Even if you don’t have an app of your own, you can help support the app developer community by spending some time getting their packaging in order.  QML apps are relatively simple when it comes to packaging, so a seasoned packaging veteran could probably knock one out in a matter of minutes.

PPA Review

You won’t have to conform to all of the requirements that you will to get into the Ubuntu archives, and there won’t be a lengthy review process.  The Apps Collection is offered up for users to evaluate and test Ubuntu Touch and apps written for it, there is no guarantee of stability or security.  Generally if it installs and runs, we’ll include it in the PPA.  But we’re not crazy, and we won’t be uploading apps that are obviously malware or detrimental to the user or platform.

Preview Image Review

Your app will need to go through a more intense review before being approved to go into the default install of the Ubuntu Touch Preview.  You code will be inspected by the engineers responsible for the preview images, to make sure it won’t cause any problems with stability or security that would interfere with the primary goal of the preview images, which is showing off the incredible user experience that Ubuntu provides on touch devices.

Inclusion

Once it’s ready, your app will join the default apps being developed by Canonical, as well as Core Apps being developed by other members of the community in collaboration with Canonical project managers, as part of the demonstration platform for Ubuntu Touch.

This is a great opportunity for you, as a developer, to get your app in the hands of a large number of early adopters.  It’s also a great opportunity for us, being able to promote off our platform and how it is being used by the app developer community.

Read more

The excitement around the Ubuntu SDK and application development is still going strong, both on the Ubuntu Touch Core Apps side and with independent developers. So strong, in fact, that it’s time for another round of updates and spotlights on the work being done.

Core Apps in the Touch Preview

Some big news on the Core Apps side is that they are now being reviewed for inclusion in the daily Ubuntu Touch Preview images being developed by Canonical for the Nexus family of devices, and by community porters to a growing number of others.

Now that all of the Core Apps are being regularly built and packaged in the Core Apps PPA, they can be easily installed on desktops or devices.  And, after being reviewed by the team building the Ubuntu Touch Preview images, three of them have been selected to be part of the default installed application set. So please join me in congratulating the developers who work to them.

For the Calendar, Frank Mertens, Kunal Parmar and Mario Boikov have done a fantastic job implementing the unique design interactions that were defined by Canonical’s design team.  For the Calculator, Dalius Dobravolskas, Riccardo Ferrazzo and Riccardo Padovani were able to quickly build something that is not only functional, but offers unique features that set it apart from other standard calculators.  Finally, the Clock app, where Juha Ristolainen, Nick Leppänen Larsson, Nekhelesh Ramananthan and Alessandro Pozzi have put together a visually stunning, multi-faceted application that I just can’t get enough of.

New Independent App Development

In addition to the work happening on the Core Apps, there has been a continuous development by independent app developers on their own projects.

LoadShedding

Load shedding (or rolling blackouts) are a way for electricity utilities to avoid being overloaded by energy demands at peak times.  This an be an inconvenience, to say the least, especially if you don’t know it’s coming.  Maybe that’s why developer razor created this LoadShedding schedule app.

Multi-Convert

Multi-Convert was originally an Android application, written in HTML5, that is now being ported to Ubuntu.  Multi-Convert allows real-time conversion of weight, length, area, volume and temperature between different standard units.

 TV Remotes

I ran across not one, but two different apps for the remote control of home-theater-PCs, bringing the promise of your mobile phone as a “second screen” to Ubuntu Touch.

First is Joseph Mills (who also created a Weather app featured in the first of these roundups), with a remote control for MythTV:

And if you’re an XBMC user instead, not to worry, because Michael Zanetti has you covered with his remote control for XBMC:

CatchPodder

If you use your mobile device for listening to podcasts, you’ll be pleased to find the nice and functional podcast manager CatchPodder, which lets you subscribe to multiple feeds as well as playing files directly from the server.

AudioBook Reader

Keeping with the theme of listening to people talk on your Ubuntu device, we have an AudioBook manager and player that is being written with the Ubuntu SDK, which lets you load books, display cover images, and more.

Bits

If you’re a software developer, sysadmin or network engineer, there’s a good chance you’ve had to convert numbers between decimal, hexadecimal and binary.  This makes Bits a very handy utility app to keep in your pocket.

Periodic Table

From the same developer who created a Software Center front-end and Pivotal Tracker (both featured in previous posts) has a new project underway, an element browser that gives you loads of detailed information about everything on the periodic table.

WebMap

Canonical engineering Manager Pat McGowan has gotten into the fun too, building an app for displaying web-based maps from a number of providers.

GetMeWheels

For Car2Go customers looking to rent or return a vehicle, GetMeWheels lets you easily find the nearest locations to you.  Created by the same developer as the XBMC remote, this app was originally developed for Maemo/Meego, but is now being ported to the Ubuntu SDK.

PlayMee

A third app from the developer of GetMeWheels and XBMC Remote is PlayMee, a local music player that again was originally developed for Maemo/Meego, and is being ported to the Ubuntu SDK.

Tic-Tac-Toe

Tic-Tac-Toe is not a fancy game, but this one developed by Hairo Carela makes beautiful use of animation and colors, and even keeps a nice score history.

LightOff

If games are you thing, you should also check out LightOff, a simple yet challenging game where the object is to turn off all of the lights, but clicking one toggles the state of every square around it.

 

That’s all for now, keep those apps coming and be sure to post them in the Ubuntu App Developers community on Google+

 

Read more

It’s official, UDS 13.05 is coming up next month, marking our second online Ubuntu Developer Summit, and coming only two months after the last one. While going virtual was part of our transition to make Ubuntu’s development more open and inclusive, the other side of that coin was to start holding them more often. The first we put into affect in March, and the second is coming in May. Read below for information about this UDS, and changes that have been made in response to feedback from the last one.

Scheduling

The dates for UDS 13.05 are May 14, 15 and 16, from 1400 UTC to 2000 UTC.  We will once again have 5 tracks: App Development, Community, Client, Server & Cloud and Foundations.  The track leads for these will be:

• App Development: Alan Pope, David Planella & Michael Hall
• Community: Daniel Holbach, Nick Skaggs & Jono Bacon
• Client: Jason Warner & Sebastien Bacher
• Server & Cloud: Dave Walker & Antonio Rosales
• Foundations: Steve Langasek

Track leads will be in charge of approving Blueprints and getting them on the schedule.  If you are going to be responsible for running a session, please get with the track lead to make sure they have marked you as being required for that session. If you would like to get a session added for this UDS, you can do so either through registering a Blueprint or proposing a meeting through Summit itself.  Both approaches will require the approval of a Track Lead, so make sure you discuss it with them ahead of time.

Changes to…

Using feedback from attendees of the March UDS, we will be implementing a number of changes for UDS 13.05 to improve the experience.

Hangouts

Google+ Hangouts have a limit of 15 active participants (if started with a Canonical user account, it’s 10 if you don’t have a Google Apps domain), but in practice we rarely had that many people join in the last UDS.  This time around we’re going to encourage more people to join the video, especially community participants, so please check your webcams and microphones ahead of time to be ready.  If you want to join, just ask one of the session leaders on IRC for the hangout URL. We are also investigating ways to embed the IRC conversations in the Hangout window, to make it easier for those on the video to keep track of the conversation happening there.

The Plenaries

Most people agreed that the mid-day plenaries didn’t work as well online as they do in person.  There was also a desire to have a mid-day break to allow people to eat, stretch, or hold a sidebar conversation with somebody.  So we are replacing the mid-day plenaries with a “lunch” slot, giving you an hour break to do whatever you need to do. We will be keeping the introductory plenary on the morning of the first day, because that helps set the tone, goals and information needed for the rest of the week.  In addition to that, we have added back a closing plenary at the end of the last day, where track leads will be able to give a summary of the discussions and decisions made.

The Schedule

In addition to the above plenary changes, we have added an extra day to this UDS, making it 3 days instead of two.  The last day will allow for overflow of sessions that couldn’t fit into 2 days, or the scheduling of follow-up session when it is determined they are necessary following a discussion earlier in the week.

Registration

Registration to attend will now be done in Summit itself, rather than through a Launchpad Sprint.  So if you’re not a track lead, and you’re not registering Blueprints, there’s nothing you need to do on Launchpad itself.  This will help those who do not have a Launchpad profile, though you will still need an Ubuntu SSO account to log in.

To register for UDS 13.04, go to the summit page, and just above the schedule you will see an orange “Register in Summit” button.  If you don’t see that, you either need to log in to  summit or you’ve already registered.

Summit Scheduler

Chris Johnston and Adnane Belmadiaf have been working hard to improve the Summit Scheduler website, taking feedback from attendees to improve the interface and workflow of the site.  We will include as many enhancements as possible before the start of UDS 13.05.  If you are interested in helping improve it, and you have some web development skills, please find them on #ubuntu-website on Freenode to find out how you can get involved.

Read more

Shortly after announcing the Ubuntu Phone, we made an ambitious and frankly unprecedented decision to make the development of the phone’s core apps a community initiative.  We weren’t just open sourcing the apps being developed by Canonical (though we did that too), we would let the community drive the design and development of what would become the foundation of the Ubuntu Touch app ecosystem.  And we would do it ten short months.

Work Item Tracking

Building 11 apps in less than a year is a lot of work, and tracking that work is itself a lot of work.  To do this, we are using the same tools and process as the rest of Ubuntu’s development.  This means using Launchpad for code hosting and bug tracking.  But more importantly, it also means using Blueprints for planning, breaking the work into individual tasks, and assigning those tasks to individual contributors.  This also allows us to use the Ubuntu Status Tracker to view the progress being made on those tasks.  As of right now, that chart looks like this:

As you can see, when we started tracking them we had about 165 work items defined, and about 140 left to finish.  As tasks are completed, and the developer updates the Blueprint with the new status of the work item, the orange part of the chart will shrink, and the green part will grow.  If we can keep the green part on or below the black line, then we’re on track to finish them all by our October goal.

Milestones

Ten months is a short amount of time to build a collection of well designed and polished apps, but it’s also a very long time for planning development work.  In order to narrow our focus and concentrate on immediate development tasks, we’ve further broken down the development period into a number of milestones, one for every month between now and October.

So instead of planning out the entire cycle, we will be scheduling tasks on a monthly basis.  This will make the amount of work seem less daunting, and also give us a more agile cycle of planning, development, and evaluation.  Each milestones will in turn get it’s own burn-down chart, so we can track the progress being made within the month as well.

Development Teams

Work items are also separated by team, which allows us to track the progress of individual projects, as well as the overall projects of the core apps campaign.

This allows teams to easily check if they are on track to complete their project  by October, and also gives them an idea of how much (or how little) work remains to be done.

Next Steps

The first milestone, coreapps-13.10-month-0 is coming up in mid-April.  For this milestone, we have been scheduling work items that were already making good progress, or that were small enough they could be completed in the two weeks between when it was defined and when it ends.

The milestone after that, ubuntu-13.10-month-1, ends mid-May, and will be our target for an alpha-level release of most of the apps.  As you can see, there is still a lot of work to be done between now and then, but we are currently below the burn-down line, so as long as we keep the momentum going we will make that goal.

Everything not currently scheduled for one of these two milestones is targeted to the final October goal.  Sometime in May we will begin scheduling work items for the coreapps-13.10-month-2 milestone, based on the progress made on these first two miles.

Read more

If you missed it, I posted an earlier round of SDK apps a couple weeks ago.  Well the pace of new app development didn’t slow down, so here I am again with another round of apps being written with what is still an alpha version of the Ubuntu SDK.

Core Apps Update

First an update on the Ubuntu Touch Core Apps project.  I highlighted a few of these already in my last post, but in the past week those apps have received several updates, and others have had the initial features start to land as well.

Calculator

In addition to being able to scroll back through previous calculations, the Calculator App developers have now added the ability to start a new calculation by dragging up and “tearing off” the current one, moving it into the history for later browsing.

Clock

The Clock app has been given a slight visual update on the main screen, and all new stop watch functionality too!

Calendar

The Calendar App now shows events for the day, and will take over the full screen to let you easily view your busy schedule.

Weather

The weather app too has added some visual features, and with the detailed design workflows just released, you can expect to see major changes coming to this app soon.

RSS Reader

The RSS Reader got off to a good start this week, allowing you to add feeds and read articles, either all aggregated together or one feed at a time.

File Manager

Finally, the File Manager is now working enough to let you browse through files and folders, and even open files in the appropriate application

Independent Apps

A man of many talents

Developer Ashley Johnson has been working on a couple of new apps using the Ubuntu SDK.  His first was a touch-friendly version of the Ubuntu Software Center:

Followed up earlier this week with an Ubuntu Touch client for the Pivotal Tracker project management web service:

Ubuntu Loves Reddit

We must, because there is not one, not two, but three separate Reddit apps being written with the Ubuntu SDK.

Ultimate Time Waster

Even Canonical’s VP of Engineering, Rick Spencer, has gotten in on the fun.  Though his app, which gathers funny pictures from across the internet for easy browsing, it’s as productivity-focuses as you might expect.

Dawning of the age of Aquarius

Canonical’s Stuart Langridge (aquarius on IRC, for those who don’t get the reference) is our resident audio-phile, which might explain why he’s written two music apps with the Ubuntu SDK, one for Ext.fm and another for Ubuntu One’s Music Streaming service.

Zeegaree

Developer Micha? Pr?dotka is porting his desktop timer app Zeegaree to the Ubuntu SDK

GPS Workout tracker

Fitness trackers are becoming more and more popular, especially as mobile apps.  Ready to meet this demand is Marin Bareta and his workout tracker for Ubuntu Touch

uQQ

QQ, the popular instant messaging service out of China, is getting it’s own native uQQ Ubuntu SDK client thanks to developer ? ? (shared to me by Szymon Waliczek)

Resistor Color Codes

I’m not electrical engineer, so I don’t know exactly what this does, but if you do I bet it would be handy to have available in your pocket, so thank Oliver Marks for making it.

Stock Tracker

Last but not least, I just saw this stock price tracker from Robert Steckroth

 

If you are writing an Ubuntu SDK app, or have come across one that I haven’t blogged about yet, be sure to drop me an email or ping me on IRC.  I get the feeling this isn’t the last SDK Apps update I’ll be posting.

Read more

Continuing with the work to refine and improve how we build Ubuntu in an open, transparent, and collaborative way, I want to take a few minutes to discuss some work going on to improve the regularity of our planning and the benefits this brings.

Traditionally planning for Ubuntu has worked like this.

• We ship a release.
• Shortly before a release we rapidly prepare blueprints for the next Ubuntu Developer Summit (UDS). Everyone is welcome to participate.
• We discuss topics at the UDS and jot down work items into blueprints.
• We then execute on those work items over the course of the six month period.
• We track this work on status.ubuntu.com and use burndown charts to visualize this progress.

While this has served us well, there are a few problems with this approach. The most notable issue is that we work in software, and a lot changes in software in a six month period. This means we define a set of work items, prepare the burndown, and then if requirements or direction changes it can be difficult to reflect those changes across our community and we have to go and postpone a bunch of work items and re-build our burndowns. This means that even though the changes are made to open blueprints, it can cause folks across our community to be out of sync. It also presents the misconception that everything at UDS is locked in for the duration of the six month cycle. If something changes in our strategy or a new opportunity opens up, it can be difficult to change course with everyone on the same page.

Solving this is part of our theme of making Ubuntu engineering as transparent and agile as possible.

One approach we are experimenting with in the Ubuntu Engineering Management team at Canonical is to increase the regularity and transparency of how we plan. Instead of locking in every six months we will do it like this:

• We host the virtual UDS (vUDS) every three months and use the event as a means to plan out the next three months of work. All discussions are open, everyone is welcome to participate.
• Blueprints will be used to track that work and work items will be divided up into monthly milestones.
• On the last week of every month we will review the work performed in the last month to see how well it was completed and then plan the forthcoming month’s work. This provides an open opportunity to identify blockers, define new goals, and change coarse if needed.
• A new burndown chart will be generated on status.ubuntu.com and we will host a Google+ Hangout presenting the goals for the next month to ensure that everyone is fully up to speed on what is going on.

Now, to set expectations clearly: this is just an idea for how to improve this workflow, and we are doing it for the first time this week, but the idea is that it will dramatically increase the transparency of which teams are working on what, making it easier for others to (a) know what is going on and (b), participate in areas of interest.

My team is currently preparing the work items for April and you will be able to see the final burndown here when it is complete. From there you will be able to see all the blueprints.

I will provide plenty of feedback on what is working well and less well, and your feedback is welcomed, as ever, in the comments.

Building Re-usable Processes

As I mentioned in my previous blog entry, we want to make virtual UDS an event that is repeatable and useful for not just UDS but also for domain-specific events too (such as a LoCo themed UDS). The goal is that this event format is repeatable for our wider community.

Likewise, the monthly planning process is also designed to be repeatable for our wider community too, making it simple to get everyone on the same page for planning and executing on awesome projects.

As ever, feedback is always welcome, but I think this combo of a wider planning event every three months combined with monthly work item sync-ups and planning will result in a pretty effective formula for helping Ubuntu to be as effective, transparent, and collaborative as possible.

Read more

Our community is at the heart of how we build Ubuntu. Recently there were some concerns expressed about some aspects of our community and I have been working with various community members and internally at Canonical to resolve some of these issues to make things smoother.

I just wanted to summarize some updates:

• Regular, transparent planning – we want to improve how we plan the delivery of work items, and make that planning more nimble. While the major decisions are reserved for primary discussion at UDS, we want to regularly and transparently checkpoint progress on those projects, and ensure things are moving along. To do this the engineering managers at Canonical will perform this planning on a monthly basis with our community. An an example, with my team, we will decide at UDS what major projects we will work on and document the work items in those blueprints, and every month I will ask the team to commit to delivering an agreed set of work items that month and update the blueprints accordingly. This will make it easier to understand who is working on what, what needs to be done, and areas in which people can participate. This entire process will be completely open and transparent and I would like to encourage our wider community to use the same approach. As an example, this could be a useful technique for our LoCo community to use for planning their work too around advocacy campaigns. All of this work will continue to be tracked openly in status.ubuntu.com.
• Training our engineers – our engineers at Canonical are expected to openly and transparently perform all work that is not considered customer/company confidential. While this expectation is clear, there are sometimes cases when this doesn’t happen (e.g. if someone joins Canonical without the experience of working in an open environment and isn’t really sure how to do this). I have prepared an internal slide deck with these expectations and workflows clearly laid out; my team will be working to ensure everyone gets the deck, reads it, and gets an answer to any of their questions.
• Regular leadership problem solving meetings – one problem we have today is that we don’t have a regular problem solving meeting in our community in which our governing leaders are present at. Instead our different leadership boards (e.g. Community Council, Forums Council) tend to resolve issues pertinent to that specific board. We think it could be useful to have a meeting every two weeks that has representatives from our different governance boards and our community can join and raise topics for discussion. We are going to run the first one of these sessions tomorrow (Tue 19th March 2013) on Ubuntu On Air at 8pm UTC. We invite you to bring your topics there on IRC for discussion.
• Online UDS refinements – as I blogged about last week we have released a survey to gather feedback about how to refine and improve UDS. We have already made some plans for some improvements but I plan on organizing a community meeting to discuss this more next week (I can’t later this week as I am at an event). I think there is an opportunity to refine the format of UDS into a form that becomes a useful and repeatable way of coordinating meetings in a community.
• Weekly Updates – I have reached out to the engineering managers on some of the core projects at Canonical and asked them to provide weekly updates of work going on. We have already seen the first updates for Ubuntu Touch and Mir.
• Prepping announcements better – while the major announcements are now out, one piece of feedback I received is that our community felt ill-prepared around things such as the Ubuntu Touch announcement, and people such as our IRC/Forums/Community councils were inundated with questions and didn’t have good answers to those questions. If we need to make future announcements in the same way again, I am going to ensure our core governance boards are clued up first and we provide a FAQ for our community to refer to when getting these kinds of questions. This should relieve this concern.
• Improving our community on-ramp – one area where I want to drive some improvements is making it easier for people to join the community. We started some work a while back to improve the community landing page on ubuntu.com and I have asked Daniel Holbach to drive that work to completion. I am also working with the Ubuntu Touch and Mir teams to ensure that they have awesome documentation and guidance for how people can participate. A good example of the progress being made here is the Mir documentation. If you would like to help improve these docs, then feel free to dig in and help, or share your ideas on the mailing lists.

I want to get as much feedback on these steps moving forward as well as other ideas and areas in which we can focus. You can always grab me on IRC on freenode (my nick is jono) and I hang out in #ubuntu-community-team. Also feel free to drop me an email and join my regular Q+A session every week. Unfortunately, this week’s Q+A session is canceled as I need to be at an event, but I will be back in the regular slot next week on Wednesday at 7pm UTC on Ubuntu On Air.

Read more