Ubuntu Developer Summit Sponsorship Now Open

Ubuntu Developer Summit Sponsorship Now Open

The [Ubuntu Developer Summit](https://uds.ubuntu.com/) (UDS) is the most important event in the Ubuntu calendar. It is where we get together to discuss, design, and plan the next version of Ubuntu; in this case the Ubuntu 12.10 release.

The next UDS takes place at **The Oakland Marriott City Center, Oakland, California, USA** from the **7th – 11th May 2012**. You can find out more about why UDS is interesting from the perspective of a [member of the community](https://uds.ubuntu.com/participate/community), an [upstream contributor](https://uds.ubuntu.com/participate/upstreams), and a [vendor](https://uds.ubuntu.com/participate/vendors). We also welcome everyone to [participate remotely](https://uds.ubuntu.com/participate/remote) if you can’t attend the event in person. More more details on how to get there, see [this page](https://uds.ubuntu.com/travel/).

At the heart of a great UDS is a diverse group of attendees who can bring their experience and expertise to the discussions. You don’t have to be technical, or be a programmer or packager to attend – UDS is open to everyone (including non-Ubuntu folks) and free to attend. We encourage everyone with an interest in Ubuntu to attend.

## Sponsorship

For every UDS Canonical sponsors the hotel and accommodation of a set of community members to ensure they are free to contribute and bring value to the discussions. We have a limited budget so we can’t sponsor everyone, but we are always keen to have a capable and diverse group to sponsor:

* We strive to support community members who are actively involved in Ubuntu and who are providing *significant and sustained* contributions to the Ubuntu project.
* We always welcome Upstream contributors who are bring value to Ubuntu indirectly via active participation in their upstream project, but who are keen to see quality support for that upstream in Ubuntu.
* Contributors are willing to actively participate not only throughout the full Ubuntu Developer Summit week, but also following with active contributions throughout the release cycle.
* We are always keen to welcome members of the community who have never been to UDS before and are keen to participate and experience the event.
* You don’t have to provide technical contributions to apply – if you have participated in the areas of advocacy, documentation, testing, art, design etc, you are encouraged to apply.
* UDS is an event that encourages diversity – we welcome everyone to apply for sponsorship, irrespective of gender, race, impairment, technical expertise, or other factors.

If you are participating in the Ubuntu community, we would love you to apply for sponsorship. This is how it works:

1. You can apply for sponsorship [by following these instructions](https://uds.ubuntu.com/participate/sponsorship/). Apologies for the different forms you need to fill in – we are going to consolidate these forms at the next UDS. The deadline for submissions is **Wed 22nd February 2012** so be sure to get yours in!
2. When the deadline is reached we will assess the applications and finalize who we will be able to sponsor.
3. You will then receive an email outlining whether we can sponsor you or not.

Simple! I look forward to seeing your applications, and seeing many of you in Oakland!

The HUD: Call For Testers

The HUD: Call For Testers

Today we announced the HUD that is landing in Unity. This is an awesome new feature. See [Mark’s blog post](https://www.markshuttleworth.com/archives/939), the [coverage on PC Pro](https://www.pcpro.co.uk/news/372385/ubuntu-rips-up-drop-down-menus), and the interview with [John Lea on OMG! Ubuntu!](https://www.omgubuntu.co.uk/2012/01/hud-new-unity-feature/). Here is a video of the feature in action:

*Can’t see it? See it [here](https://www.youtube.com/watch?v=w_WW-DHqR3c)*.

I wanted to point you folks at [Nicholas’s blog post](https://www.theorangenotebook.com/2012/01/testing-hud-heads-up-display.html) about how to test the HUD. You will need to be running Ubuntu 12.04 (which is still in development) to test.

We would like to encourage everyone to test so we can get this rock-solid for 12.04!

From Old To New Python GTK

From Old To New Python GTK

I am a pretty terrible programmer. Anyone who has read my code can see that. Unfortunately, I tend to have lots of ideas about how we can use technology in different ways, hence why I write some code. Examples of this have included Lernid, Acire, RaccoonShow, and Jokosher.

Fortunately (or unfortunately, depending on your view), I have had Python and GTK to serve my needs here. Python, with it’s awesome batteries-included range of facilities and GTK as a simple yet flexible toolkit has allowed me to create implementations of the ideas that I have dreamed of. I started using these tools many years ago, and they have always provided a simple and effective toolset for me.



My preferred toolset of choice. One day…

Having not written any code for a while, I got the itch this weekend to start writing the [trophy helper app that I wrote about as part of the accomplishments system](https://archivedblog.jonobacon.com/2012/01/23/hacking-on-accomplishments/) spec that I created with Stuart Langridge and Daniel Holbach. I thought this would be a good opportunity to brush up on my skills, given that PyGTK is dead and the new world is instead the GIR approach to GTK. In a nutshell, this is where the language bindings basically match the C API for GTK thus reducing the need for people to maintain different language bindings.

Of course, this is a good thing: less work for volunteers in maintaining multiple-language support for GTK and a consistent API is good. Unfortunately, I found getting started with this new world a little more complex than I imagined.

From reading the documentation it suggested that all I needed to do was to import `Gtk` from `gi.repository` and instead of creating widgets with `gtk.` that they would be `Gtk.`. The docs suggested a few other lexical adjustments, but not much more than that. There is even a [pygi-convert.sh script](https://git.gnome.org/browse/pygobject/tree/pygi-convert.sh) that can convert older PyGTK code over to the new PyGI way. Unfortunately the script didn’t work for me, so I instead used it as a cheat-sheet for things that needed changing. Sadly, it seemed like some things were not covered in the script.

An example of this included when I was creating a `ListStore`. In PyGTK code I could add a `gtk.gdk.Pixbuf` to the ListStore for an icon, but I had a difficult time trying to figure out the new way to describe this. I tried `Gtk.gdk.Pixbuf` and `Gtk.Gdk.Pixbuf` but had no luck. Fortunately the awesome *Ryan Lortie* informed me that it needed to be `GdkPixbuf.Pixbuf`. Another example of this was `gtk.SORT_ASCENDING` in my original code and the new `Gtk.SortType.ASCENDING` in the new code. It seems like various functionality in GTK has been moved around and re-factored.

Unfortunately I could not find any documentation to help me with this. Sure, the C docs are available online, but I am not a C programmer; I am (in the most generous and understanding way) a Python programmer and where I previously had a pretty decent tutorial and reference guide to PyGTK, as a desktop app developer I no longer have these resources to help me. Even though I am not a fantastic programmer, I have written enough Python and GTK code to fumble my way through writing various apps, and if it stumped me as a relatively old hand, I wonder how a brand new developer would get on.



Pictured: old hand.

Now, this may sound a little critical, but it is not mean’t to be. I have tremendous respect for the GTK team, and I am hugely thankful to them for all their hard work. I am also thankful for the team that has worked on the GIR support so that multiple language support can be more efficiently provided. Thanks to all you folks for providing great tools that let a programming numpty such as myself be able to write Free Software.

I just wanted to share this because I feel like these tools are missing the final component: if we had a good solid set of reference documentation generated for each language (naturally, Python is the language I mainly care about), this would help novice and established developers use GTK more effectively. From my personal experience, my patience started wearing pretty thin when I felt like I didn’t have anywhere to find help as I navigated C documentation to try and figure out how the API fitted into my Python application. A good solid Python reference manual would have resolved this issue, and from what I understand, this could potentially be generated from the GIR files. Unfortunately, I don’t think I have the skills to help solve this problem, so I figured the best I could do was to share my story and see if anyone would be interested in helping to solve this problem.

If so, thanks in advance, and thanks again to the GTK team for all your hard work!

### Update

I found [this excellent documentation](https://readthedocs.org/docs/python-gtk-3-tutorial/en/latest/) after publishing this entry. This provides exactly the kind of documentation I was looking for. Thanks to anyone who helped contribute to this!

From Old To New Python GTK

Nicholas Skaggs QA Blog

A little while back [I mentioned that Nicholas Skaggs would be joining the Community Team](https://archivedblog.jonobacon.com/2011/12/12/nicholas-skaggs-joining-the-canonical-community-team/) at Canonical. Nick is now on board but is not an Ubuntu Member yet, so his blog is not appearing on [Planet Ubuntu](https://planet.ubuntu.com).

On his blog he will be talking about improving our QA infrastructure and documentation, building out manual test coverage, and growing a community of QA testers.

You can read his blog [here](https://www.theorangenotebook.com/). I am going to ask Nick to apply for Ubuntu Membership in a few months when he has provided a significant and sustained contribution, and then his blog will appear on Planet Ubuntu.

Ubuntu Developer Summit Sponsorship Now Open

Hacking On Accomplishments

A little while back I [blogged about](https://archivedblog.jonobacon.com/2011/10/25/ubuntu-accomplishments-system-spec/) an accomplishments system that [Stuart Langridge](https://www.kryogeniz.org) and I designed when he came to visit a while back. The idea was simple: a de-centralized system in which we can easily define different types of accomplishments (e.g. filing a bug, submitting a patch, getting a patch sponsored, translating a string) and a means in which users can be rewarded trophies for these accomplishments as well as discovering new accomplishments and how they can be achieved.

The nice thing about the system we designed is that it is de-centralized, it uses Ubuntu One as a transport mechanism (which means we don’t have to build our own transport system and your trophies are visible across all your Ubuntu machines), and the system has a verification process to ensure that people can’t fake their community accomplishments.

I wrote this all up into a spec which you can find [here](https://wiki.ubuntu.com/AccomplishmentsSpec).

We had an interesting session about this topic at UDS and Stuart put together a draft implementation which is at `lp:~sil/+junk/libaccom-draft/`. The implementation defines a set of sample accomplishments and provides a daemon that runs to maintain state on which accomplishments have been achieved and which are still yet to be completed. The system is neatly integrated into Ubuntu and accomplishments are displayed in a notify-osd bubble:

Stuart also wrote a small API (`libaccomplishment`) that client apps can use to query the system and present trophies achieved or those yet to be achieved. You can read more about this draft implementation [here](https://wiki.ubuntu.com/AccomplishmentsSpec#Draft_Implementation).

In the original spec there are two clients that would be in the system. A lens:

…and a helper app that is loaded when you click on a trophy in the lens which can provide more information about an accomplishment as well as showing the list of achieved accomplishments and those yet to achieve:

This weekend I decided to start writing this helper app (Michael Hall has expressed an interest in writing the lens). To get things rolling I wanted to display the list of trophies that have been accomplished. It looks like this so far:

This app is using the `libaccomplishment` API that Stuart provided in his draft implementation and this code could obviously used to develop the lens. There is obviously still lots to build into the app, but it provides a useful proof-of-concept for how it could work. This is a Quickly project and you can grab the code from `lp:~jonobacon/junk/trophyinfo`.

If you want to play with this, grab Stuart’s draft implementation (`lp:~sil/+junk/libaccom-draft/`) and run `examples/demo.sh` – this will start the daemon. You can then grab my branch (`lp:~jonobacon/junk/trophyinfo`) and run `quickly run` and see the trophies in the view.

Everything so far has been something of a proof of concept, but I wanted to see if anyone else was interested in participating. There are a number of things that we need to do:

* Stuart’s draft implementation needs extending, and he would like to find a new owner for it. Currently the API is simple but might need fleshing out further.
* The helper app here that I created a first cut of needs expanding and functionality added. We need to provide different ways of filtering the trophies, providing information about a specific trophy and how to achieve it, and the other features outlined in the [spec](https://wiki.ubuntu.com/AccomplishmentsSpec).
* Each accomplishment has a script that is run to see if you achieved something (e.g. if you filed a bug in Launchpad). In the spec, when one of these scripts returns that you accomplished the task, it creates a trophy, and syncs it via Ubuntu One to a validation server which runs the same script to verify you really did achieve the accomplishment. This then signs the trophy which then syncs back to your machine. We need someone to build this verification service.
* We need to evaluate and extend the .accomplishment format to include documentation for how to achieve a trophy. I know Jim Campbell expressed an interest in working on this and I would love to encourage others to participate too.
* We need to create a library of Ubuntu Community accomplishments. Stuart’s draft implementation includes an example script for filing a bug. See the [list of ideas](https://wiki.ubuntu.com/Accomplishments/Trophies) that Daniel has been working on.

Anyone interested in taking part?

### UPDATE

Since I posted this I have made a bunch of improvements to the helper app. This includes:

* The app now displays trophies achieved on the My Trophies page and those not yet achieved on the Opportunities page.
* Locked trophies (i.e. those that need another trophy to be accomplished before it can be) now use a different icon (we will need new icons for all of these, so I am using stock icons right now).
* Trophy/opportunities status is now updated with each page load which means that trophies are updated more dynamically.
* Double-clicking an opportunities will take you to the WebKit page to display info about it. I just need to update the .accomplishment scheme to provide more useful info.

I pushed all these updated to `lp:~jonobacon/junk/trophyinfo` if you want to play with it. 🙂

Community Team Goings On

Community Team Goings On

A week ago I flew to Budapest for an Ubuntu Engineering Team Rally. This is where we get the Ubuntu Engineers at Canonical and some other groups together for a week to work together, plan future work, have meetings and make progress on our existing commitments. It is in this week that I gather together with the guys on my team and we have the rare privilage of working together from the same office (we all work remotely usually).

Daniel Holbach, Jorge Castro, and David Planella were there, and we welcomed Nicholas Skaggs to the team who started his first day at Canonical on the first day of the Rally; a brave man! Unfortunately Michael Hall could not join us, but we had a tablet with his gleaning smiling face beaming into our room on Google+. He was there in spirit, if not physically.



Chris Farley was also there in spirit, if not physically.

We made some great progress and [put quite a dent in our burn-down chart](https://status.ubuntu.com/ubuntu-precise/canonical-community.html), but I wanted to summarize some of the work going on right now that might interest you:

* David, Daniel, and I spent quite some time opening up the ARB process and helping to get things back on track. We now have a flow of lenses coming through and the queue is looking in better shape. Thanks to the ARB for their work here and we will be continuing to build refinements into the process over the coming weeks.
* Nick got on-boarded at the event and met the QA team (Gema, John-Baptiste, Carlos, Pete etc). We discussed plans around putting in place a manual test case system (we will be piloting Case Conductor). We also centralized QA communication channels (#ubuntu-testing on Freenode) and Nick started cleaning up the documentation for how people participate in Ubuntu QA. I am excited by the progress happening here…more to come soon!
* Jorge made further progress on the charms front and we planned out a tour of events to run charm schools. Good progress is being made on upstream charm targets and awareness of Juju is growing.
* David and I discussed next steps for [developer.ubuntu.com](https://developer.ubuntu.com). Things will be on hold a little in this cycle due to the web team being re-assigned to other work. Instead we are fixing up chunks of developer.ubuntu.com, particularly around publishing apps and reference materials.
* Daniel (who just got back from an awesome holiday in Morocco) and I synced up on the sponsorship queue which has got a little out of shape recently, so Daniel is re-focusing on that over the coming week as well as building out the developer advisory group and identify prospective developers and providing 1-on-1 guidance to get them through the developer process.
* Michael is going to be putting in place a patch pilot scheme for the DX team to ensure community merge proposals are getting through in a timely manner. He also coordinated the move from `#ayatana` to `#ubuntu-unity` on Freenode.
* Michael also connected with Jorge regarding the transition of Unity responsibilities and he will be coordinating further relationships with upstreams. The goal here is simple: encourage more participation in Unity development as well as the consumption of our APIs by upstreams.
* I spent some time with the team on team-related workflow. Everyone is pretty happy with how we are working, are happy with the public IRC meetings and comfortable in how we are tracking our work and moving forward on projects.
* We discussed raising the awareness of cool things going on in Ubuntu and discussed how we can provide a more representative view of this work across blogs and social media. You can expect more blogging out of our team and other teams.

Of course, there were many other things that happened, but these were some of the main ones. Remember you can keep up to date with out work on the [burndown chart](https://status.ubuntu.com/ubuntu-precise/canonical-community.html) and in `#ubuntu-community-team` on Freenode.

Experimenting With Email

Experimenting With Email

Like many of you I get a lot of email, and like many of you I often struggle to keep up with it in the context of everything else that is going on. Recently I have been trying a few little experiments in adjusting my email workflow to see if I can be more productive. I am seeing some good results and just wanted to share a few small changes I have made that have impacted my workflow in the interests of them possibly being useful for you too:

* **Using the GMail web interface** – I back-end all my mail in GMail and traditionally use IMAP to access it via the default email client in Ubuntu (e.g. Thunderbird). While I love Thunderbird and Evolution, unfortunately GMail IMAP access is a touch slower than I would like (I have talked to Chris Coulson about this issue in Thunderbird who has looked into it) and the small delay in loading messages makes the email experience feel a little less sleek. Using GMail directly removes this slight lag, and it has made the email experience feel more satisfying (obviously for those of you who don’t have this lag, such as POP users, should be fine). Importantly, if you use GMail too, check out the GMail labs split pane view which makes GMail act like a traditional email client; I find that it makes GMail useful for me as opposed to the traditional view.
* **Top posting** – I realized recently how anal I am about laying out my messages and replies. I hit reply, say hi to the person, respond inline, make sure there is space between my response and the quoted text, add my name etc. For most 1-on-1 conversations this level of layout is not really needed (although on mailing lists I still bottom post), and just hitting reply and typing without all this laying out makes email feel so much more efficient.
* **Don’t star mails to reply to** – my traditional email workflow is that I wake up in the morning, grab my tablet, and while I wake up I read my email and star all the mails I need to respond to. I then grab breakfast, do all my calls, and then get to the starred emails to respond to. Instead of starring I experimented by marking emails unread that I need to reply to. For some reason this makes the urgency of replying more amplified in my head. I think that I just don’t like seeing unread emails, and it flips a psychological bit that makes me want to reply to them quicker as opposed to starring and my email just being another list of things to tend to. I know sounds a little strange, but this small change also affects how I handle my email.

Of course, while these things work for me, many of these won’t be of interest or work for you folks, but some may, and I just wanted to share them. I am sure there are lots of little tweaks to your own email workflow that you have found useful, and I would love to hear them in the comments. Happy emailing!

Community Team Goings On

Testing Required: Unity PPA

The always awesome [didrocks](https://blog.didrocks.fr) posted yesterday to encourage the testing of the Unity PPA. In this cycle we have changed how Unity is deployed into Ubuntu by required a set of acceptance criteria tests before it enters the archive. As such, much of the testing of the new Unity releases is happening in a PPA and then when a new Unity release is ready, it is added to the 12.04 development branch.

Not only this, but the PPA includes a set of checkbox tests that you can use to provide solid feedback on many different elements of Unity. If you can take a little time to grab the PPA and run through the tests, that would be great.

I have tested this most recent release in the PPA, and I am stunned with how solid Unity feels.

I wanted to share [didrocks’ post](https://blog.didrocks.fr/post/Releasing-a-precise-Unity-5.0-to-Ubuntu-12.04) but his blog is currently down (he knows and is resolving it), so I wanted to republish below. Be sure to grab the PPA and test on 12.04!

Here is the post:

> The [Canonical](https://www.canonical.com) ubuntu platform and product strategy teams are gathering in Budapest this week to tackle as much work as possible on precise pangolin. Despite the promise of snow and cheap beers, we are working hard on getting Unity 5.0 out of the door.

> One of the goal of this release is to increase quality, precision, no regression on the work we push to the unstable version of ubuntu. The desktop experience team made automated and manual tests for that and we can already see the first benefits from it. We pushed an [automated building infrastructure with public test reports](https://jenkins.qa.ubuntu.com/view/Precise%20Unity%20Merger/) to have commits automatically tested, pushed to the [trunk of development branch](https://en.wikipedia.org/wiki/Trunk_(software)) as well as available packages in a ppa.

> With all those news features and requirements, we needed to redesign the release process and that’s what we have done last Monday. Let me expose the few steps I will explain there.

> 1. On Monday evening, we have frozen the trunk, which means, no more new code can enter unity at this point (as well for all the related components like unity-2d, nux, dee, libunity, bamf, unity lenses). Only selected branches can now get in, and those are picked only if they contribute to getting closer to this release quality.
> 2. Then, after ensuring on Tuesday that people can safely install the new release candidate, the [unity-team ppa](https://launchpad.net/~unity-team/+archive/ppa) started to contain the whole latest of what will soon be the 5.0 version of unity. If you install from this ppa, you will see a kind prompt asking you to contribute when logging back to your desktop.
> 3. This prompts help getting to our main goal, which is ensurin the quality of the new release. Multiple things have been put in practice for that. The desktop experience team qualified the release using their manual tests and running automated ones again. [Aurélien](https://agateau.wordpress.com/) and I run our own manual tests (120 of them, trying to covering the whole Unity functionnalities). This finished on Tuesday evening (we rephrased some) and we rebuilt all needed packages again, as well as some other dependencies like update-manager, usb-creator, nautilus, empathy, and gwibber to still make them working when you install from the ppa (ABI bumps). From those test we spotted regressions and get them fixed/fix them, regenerate everything and such.
> 4. The manual test wrapper over checkbox is also automatically installed from the ppa. Which means that *YOU* can help too! I’m bootstrapping this process with the [French Musketeers](https://www.markshuttleworth.com/archives/938) to ensure everything is correct and ready for the next release. How to help there will be widespread for Unity 5.2. More on that soon!
> 5. On Thursday morning, we will collect the results from the tests, see what’s still needed to be fixed (if it’s the case) and then cycle back on the previous steps.
> 6. At the same time, the bugs that are fixed will be milestoned, some cleanup will be done and everything will be then ready to format an explicit text of what’s in the new release.
> 7. Then, the process is well known: we will issue tarballs for every projects we need to upload
> 8. Packaging them properly, with the right build-dependencies and needed tweaks will be done, and upload to precise to share the love!
> 9. Finally, every non fixed bugs but targeted will be reported to the next milestones.

> And that’s it! Everyone will be able to enjoy the whole new shiny Unity 5.0, containing a bunch of bug fixes, as well, as all the layout and ground for being rock solid, speeded up and just… precise Unity version!