Another Linux distro updated now with Lubuntu in its core: DEFT Linux 7. This is a great recovery and forensic distro with lots of tools to aid for repairing partitions, damaged clusters, recover lost data, make network tests and configurations, etc. I can't write the whole list of apps included in this release, not enough space :)   Mmm, thatartwork sounds familiar to me... :D

In playing with some tools I’ve run into at $work, I’ve tried loading in some Ubuntu datasets in some fun and interesting ways.

Today, I’ve chosen to map all Ubuntu Members with a public lat/lon, sized by Karma.

The sizes relate to if the Karma is greater then:

1: 10

2: 50

3: 100

4: 500

5: 1000

6: 2000

7: 7000

8: 15000

9: 25000

10: 50000

So, without further adieu, here’re some maps!

We’re going out for the Planning Curry for season five of the Ubuntu Podcast this week. Over the years, it has become a tradition for all the presenters to go out for a curry before the start of the season. It’s a time to catch up in person, as we haven’t seen much of each other since the end of the last season. But it’s also a chance to discuss any changes we want to make to the show and throw ideas for new segments around. So, if there’s anything you’d like to see in the new season, whether it’s an idea for a segment or a change to something we already do, please let us know. You can leave a comment on this blog post or get in touch using any of the methods on the show website. Thanks!

FCM reader Brian has pulled together my Scribus tutorials from the early issues of FCM and even added updated screenshots to it. So, if you’re thinking of creating a publication of any kind, you might want to check out this special edition.

http://fullcirclemagazine.org/scribus-special-edition/

I have been passionate about Free Software for a long time now. My contributions have always revolved around helping people make amazing things happen and realize what they are really capable of. I’ve shown many people that small niche that just fits them perfectly and seen them grow from there and make a difference.
Along the way I’ve always come accross two problems:

1. “I can’t do X (usually programming), how could I ever be useful to a project”
2. “This is so overwhelming, I don’t even know where to start.”

I’ve done a lot of things to overcome this but it wasn’t ever enough somehow. Today I am at FOSDEM presenting a book, that will be another step towards fixing these problems. Today I am releasing Open Advice.

Open Advice is the result of the collaboration of more than 50 people from all across Free Software. It is a collection of short essays about key things the authors wished they had known when they started contributing to Free Software. It’ll give a headstart to everyone who wants to contribute. It’ll also be useful for existing contributors who want to know a bit more about other projects and areas of contribution.

The book is available as a paperback and free PDF and is licensed under CC-BY-SA.

What are you waiting for? Download the PDF version today or order a printed version.

Additional goodies: The LaTeX source is available and a bug tracker exists as well.

A year ago I started working on this project and today it is reality. If you’re at FOSDEM I’m sure you can see me bouncing around with joy

It’s that time again. Alpha 2 was released yesterday, here is one members experience:

http://ubuntuforums.org/showthread.php?t=1919854

There have also been several threads on kernel panics with the 3.2 version:

http://ubuntuforums.org/showthread.php?t=1913073

http://ubuntuforums.org/showthread.php?t=1896087

http://ubuntuforums.org/showthread.php?t=1910857

My own problem was solved by removing an SD card from the card reader, but that really is only a work around. The problem looks to be solved with the next kernel release.

The classroom session effenberg0x0 and I put on at UDW went well, but we found we had to much information for the length of the session. We are in discussion about doing some sessions using the Community Learning Project.

You're gonna catch a cold
From the ice inside your soul
Christina Perri — Jar of Hearts

I bet at four o'clock this morning you weren't in a police station.

Or, at least, if you were I bet you were drunk and I bet it wasn't voluntary.

After the usual Friday night poor showing from my local pub (people who follow me on twitter will be aware that the torture of watching a hundred people think they're affirming their lives by singing Mr Brightside at the top of their voices is a regular part of my balanced weekly diet), I walked home, on a cold and cloudless night. I live about ten minutes walk from town, so the walk's no hardship, except that I was dressed in shirt and no coat and it was, as mentioned, cold.

I need to be clear about this. Ten degrees below zero, Celsius, is seriously chilly when you're standing in it in shirt-sleeves. I'm sure people in actually cold places like Canada or Minneapolis or Refrigeration, North Dakota will be laughing mockingly at this point, but firstly, bugger off, secondly I bet you lot bother to put a coat on when you go out, thirdly it's not two in the morning for you, and fourthly bugger off.

Anyway, I get home and... no door key in my pocket.

You know that feeling when the Fist of Fear grabs your balls when you realise something disastrous has happened? (I don't know what the Fist grabs for women. Feel free to fill me in, or actually maybe not.) Anyway: yeah, that. I went through the usual search-all-pockets-and-then-search-them-all-again routine, just in case a mischievous cold-tolerant leprechaun hid my key from the first search and then put it back, and... no door key. Oh dear.

I'll tell you this; the walk back to the pub again seems a much longer trek. Nowhere near as long as the second return to the house without my key, though, after it turned out no-one had handed it in. And now, what the hell to do, eh? I'm not prescient enough to hide a key in the garden, especially since that's a damned good way to come home one night and find no television where a television used to be, so... locksmith? Do they have 24-hour locksmiths? I can't be the first moron to have done this.

If you're bored today, I have a suggestion for you. Go and find a dude who claims to be a 24-hour locksmith and punch him in his stupid lying face.

Incidentally, how in Jah's name did anyone manage in this situation five years ago without a smartphone, huh?

Not that the internet helps when no-one frigging answers their supposedly-24-hour phone. Also, it turns out that about four of the local 24-hour locksmith companies are actually the same company, who did answer their phone, agreed to send someone, and then after an hour of me standing in the freezing bloody freezing cold confessed that they didn't actually have anyone to send.

It's now half three in the morning, and the shivering is starting to get on my nerves, and I can't get into my house without destroying something like a double-glazed plate glass window which will cost me hundreds of pounds to fix and my hands are shaking enough that I can barely light a cigarette, let alone throw a brick through a door that probably wouldn't break anyway, and I'd like to avoid the police showing up since I have no way of proving that I actually live here except for being able to describe where all the broken bits of skirting-board are, and everywhere is closed and the doors are all locked and it's really spectacularly bone-shudderingly mightily arse-clenchingly ridiculously psychopathically cold, and what to do? I tried sleeping in the shed. Now, cold is not like wind. Being inside a thin empty wooden building does not protect you from it. I was shivering like a jackhammer on a bouncy castle and it was becoming clear, even in my not-very-operational brain state, that lying on the floor at minus ten with only a shirt on could quite possibly lead to me actually freezing to death for real.

Well, if the police came, either I'd get into the house or they'd arrest me, and being arrested would at least make me warm, and right now I'd cut my right hand off if Pol Pot showed up as long as he brought a pair of gloves and some soup.

And then, through the frozen and frosty neurons came the sparkling thought that the police station would be open, wouldn't it?

I actually felt warmer just at the thought. Not much warmer, though.

Anyway, that's how I came to be sitting in the cop shop voluntarily at four am. One lovely copper even made me a cup of tea after I poured out my tale of woe in one long sentence, breaking only for my teeth to chatter together like I was trying to bite through the world.

Police stations: while I appreciate that you're generally there to deal with miscreants and so on, it wouldn't kill you to get rid of two screwed-to-the-ground plastic chairs and put in, say, a chaise longue. After switching my phone to airplane mode I managed to eke out enough battery life that I could sit and read while huddled up against the radiator for five hours until nine o'clock this morning, whereupon I went and fetched the spare key from my estate agent after the longest and coldest and most sleepless night I have ever experienced.

So, tips, for surviving a similar situation.

1. Have a spare key. Note: I do not have a spare key hidden in my garden, burglars, so don't go looking for it. I do not know how to have a spare key somewhere where you can get at it but thieves cannot; suggestions welcomed.
2. Have a girlfriend so that there's someone to let you back in.
3. Next time you see a policeman, be nice to him.

I think I might have a nap now.

I prefer the following CSS:
<html>
<body>
<head>
<style type="text/css">
@import url(/css/style.css);
</style>
</head>
</body>
</html>

But not all browsers support @import. I wanted to see exactly which ones didn't so I used browsershots.org with a simple test.

Here are the results: http://browsershots.org/http://volatileminds.net/import_test.html

Black means it supports it. White means it doesn't.

We have uploaded a new Precise linux kernel. Please note the ABI bump. The most notable changes are as follows:

* Rebase to upstream stable v3.2.3 and essentially v3.2.4

The full changelog can be seen at:

https://launchpad.net/ubuntu/+source/linux/3.2.0-14.23

Even though some of these tools have been around for years, I have only recently started using them.
* byobu - nicer than plain screen with good defaults, for example key binding for scrolling is like in a regular terminal.* sbuild - nicer than pbuilder, defaults to overlay directory instead of tarball, hence fast by default, nice colors, build summary. I have heard about it for a long time, but the recent mention during Ubuntu devel week made me curious. It is friendlier now - no need for LVM snapshots. http://wiki.debian.org/mk-sbuild* syncpackage - which now allows syncing from Debian if you have Ubuntu upload rights. No need to burden the archive team members anymore for every sync or go the roundabout way of getting from Debian and then uploading manually without changes.* Modern Debian packaging in the form of the 3.0(quilt) source format and the new dh tools. The former allows a cleaner separation between the upstream and distro bits while the latter makes the debian/rules file much shorter and cleaner even than with CDBS, let alone with the classic debhelper way.* Twitter Bootstrap - mostly unrelated to packaging or command line stuff, but very nice regardless. CSS+Javascript UI elements that for me at least make jQueryUI superfluous, while being promoted as 'oh, just a CSS framework and style guide, not much else'.

A new great tool ready for using with our beloved Lubuntu: LxScreenshot! This is another brilliant creation from the Stefano, the same author of LxFind. You can imagine what's its purpose, creating screen captures with ease and a simple interface, with timing capture (in seconds) and the option to choose the folder to save it on.    You can install this tool just by looking for it with

Haven't tried LxFind yet? For those who doesn't know it, it will be the default file and document search tool or Lubuntu. For trying it (remember, it's not an ultimate comilation) put this on a terminal: sudo add-apt-repository ppa:lubuntu-desktop/ppa && sudo apt-get update && sudo apt-get install lxfind  If you already added our PPA just install the package "lxfind".

0 A.D. is an awesome cross-platform game that is fun, has stunning graphics and is completely open source.
There's even a PPA for Ubuntu.
It works wonderfully on both my laptops.

They are looking for a round of donations to pay for some more development work, and as of this moment they're $634 USD short. I've just sent $50 their way.
If you've got a few bucks to spare, please send some money their way. Or maybe you want to get into some development work, they have detailed instructions on how to do just that!

It took a while to get some apt resolver bugs fixed, a few packages marked for multi-arch and some changes in the Ubuntu LXC template, but since yesterday, you can now run (using up to date Precise):

• sudo apt-get install lxc qemu-user-static
• sudo lxc-create -n armhf01 -t ubuntu — -a armhf -r precise
• sudo lxc-start -n armhf01
• Then login with root as both login and password

And enjoy an armhf system running on your good old x86 machine.

Now, obviously it’s pretty far from what you’d get on real ARM hardware.
It’s using qemu’s user space CPU emulation (qemu-user-static), so won’t be particularly fast, will likely use a lot of CPU and may give results pretty different from what you’d expect on real hardware.

Also, because of limitations in qemu-user-static, a few packages from the “host” architecture are installed in the container. These are mostly anything that requires the use of ptrace (upstart) or the use of netlink (mountall, iproute and isc-dhcp-client).
This is the bare minimum I needed to install to get the rest of the container to work using armhf binaries. I obviously didn’t test everything and I’m sure quite a few other packages will fail in such environment.

This feature should be used as an improvement on top of a regular armhf chroot using qemu-user-static and not as a replacement for actual ARM hardware (obviously), but it’s cool to have around and nice to show what LXC can do.

I confirmed it to work for armhf and armel, powerpc should also work, though it didn’t succeed to debootstrap when I tried it earlier today.

Enjoy!

Last month i get a call  and email from FOMCA representative asking community to support their national program  Access to Knowledge- National Campaign on A2K Policies  , Campaign to promote Open Source Software to consumers . We (Ubuntu-my) are more than happy to corporate and collaborate with FOMCA to do our best to make the policy & campaign success. I will bring this topic to our 1st Ubuntu-my Meetup for 2012

Overall objective: Increase the uptake of free, legal software for Malaysian consumers
Specific objective: Create awareness among Malaysian suppliers and consumers to encourage the use of open source software which is the Ubuntu Linux instead of FreeDOS to provide a better computing experience and also reduce piracy

Activities:
1. Conduct an awareness seminar/workshop on piracy issue and access to knowledge. In this session, we can introduce the Ubuntu Linux operating system and how vendors and consumers can play a role in fostering the uptake of open source software and thereby reducing piracy.
2. Collaborating with the local community to promote the use of Ubuntu Linux among consumers
3. Promoting this campaign in our existing consumer websites under FOMCA.

Impact expected:
Consumer to have at least an awareness of the existence of free open source software and that they do have an alternative choice and at the same time can help in reducing piracy without having any disadvantage. We aim for this campaign to get the attention of the
industries as well as the government to come up with policies to encourage more open source software and move towards having more awareness session to make consumers understand and aware of their choices.

Here i share the full post by FOMCA and draft brochure for the awareness program.

I also hope that Ubuntu Community Globally & FOSS Community will give us support to make this happen ! \0/ May Ubuntu will r0cking all over Malaysia …

(This is part 2 of the PyQt+WebKit experiments series)

In Part 1 I described how to embed WebKit in a PyQt application and how to expose PyQt objects in WebKit and manipulate them with JavaScript.

Even if you are a great JavaScript master, you can’t avoid the occasional typo while writing JavaScript code in your application. This can be quite frustrating with QtWebKit because it likes to stay quiet: it won’t tell you about any error.

Let’s have a look at an example.

First here is loader.py, a simple Python script which loads a block of HTML:

import sys from PyQt4.QtCore import * from PyQt4.QtGui import * from PyQt4.QtWebKit import * class Window(QWidget): def __init__(self): super(Window, self).__init__() self.view = QWebView(self) layout = QVBoxLayout(self) layout.setMargin(0) layout.addWidget(self.view) def main(): app = QApplication(sys.argv) window = Window() html = open(sys.argv[1]).read() window.show() window.view.setHtml(html) app.exec_() if __name__ == "__main__": main()

And here is “broken.html”, our broken HTML code:

<html> <head> <script> function brokenFunction(arg1, arg2) { var result; result = arg1 * 2; result += arg2; resul /= 4; return result; } </script> </head> <body> Complex computation: <script> document.write(brokenFunction(2, 3)); </script> </body> </html>

Notice the missing ‘t’ in “resul /= 4″?

The last-resort, grandpa-debugged-js-this-way, debugging tool is still there: the mighty alert() function. Just stuff your code with calls to alert() and be happy… Anyone ever wrote code like that?

<html> <head> <script> function brokenFunction(arg1, arg2) { var result; result = arg1 * 2; alert("1"); result += arg2; alert("2"); resul /= 4; alert("3"); return result; } </script> </head> <body> Complex computation: <script> document.write(brokenFunction(2, 3)); </script> </body> </html>

Easy enough, no? With the great alert() function we can quickly pinpoint the bug in our brokenFunction() is between alert(“2″) and alert(“3″).

Can we do better?

alert()-style debugging gets old very fast. Clicking that “OK” button is a pain. Fortunately, there is a way to get more useful feedback from our PyQt application.

The job of the QWebView class is to show the content of a QWebPage instance. By default QWebView creates its own instance of QWebPage, but it is possible to replace this instance with our own QWebPage. The QWebPage class has a few virtual methods. Among them, the javaScriptConsoleMessage() method is the one we are looking for: it is called every time console.log() is called from JavaScript.

Here is an implementation of WebPage which uses Python logging module to get JavaScript console messages out:

import logging from PyQt4.QtWebKit import * class WebPage(QWebPage): """ Makes it possible to use a Python logger to print javascript console messages """ def __init__(self, logger=None, parent=None): super(WebPage, self).__init__(parent) if not logger: logger = logging self.logger = logger def javaScriptConsoleMessage(self, msg, lineNumber, sourceID): self.logger.warning("JsConsole(%s:%d): %s" % (sourceID, lineNumber, msg))

And here is “loader-log.py”, a loader which uses this class:

import os import sys from PyQt4.QtCore import * from PyQt4.QtGui import * from PyQt4.QtWebKit import * from webpage import WebPage class Window(QWidget): def __init__(self): super(Window, self).__init__() self.view = QWebView(self) self.view.setPage(WebPage()) layout = QVBoxLayout(self) layout.setMargin(0) layout.addWidget(self.view) def main(): app = QApplication(sys.argv) window = Window() html = open(sys.argv[1]).read() window.show() window.view.setHtml(html) app.exec_() if __name__ == "__main__": main()

If we load “broken.html” with “loader-log.py” we get the following on stderr:

$ python loader-log.py broken.html WARNING:root:JsConsole(undefined:0): ReferenceError: Can't find variable: resul

That should make it easier to find and fix our bug, even if we don’t get very useful file names or line numbers.

javaScriptConsoleMessage() receives all console messages. This means our logger will also print out calls to console.log(). Here is “console-log.html”:

<html> <head> <script> function chattyFunction(arg1, arg2) { var result; result = arg1 * 2; console.log("result" + result); result += arg2; console.log("result" + result); result /= 4; console.log("result" + result); return result; } </script> </head> <body> Complex computation: <script> document.write(chattyFunction(2, 3)); </script> </body> </html>

When loaded with “loader-log.py”, we get this output:

$ python loader-log.py console-log.html WARNING:root:JsConsole(about:blank:5): result: 4 WARNING:root:JsConsole(about:blank:5): result: 7 WARNING:root:JsConsole(about:blank:5): result: 1.75 Not good enough?

Getting the output of console.log() is nice, but modern browsers have much more efficient tools: if you open “broken.html” with Rekonq and look at the output in the Web Inspector Console, you can not only see console output, but you can also easily inspect your HTML tree and many other things.

Like us, Rekonq uses QtWebKit, so is there a way to get a similar tool?

It is actually possible. Rekonq uses a class named QWebInspector. All that is necessary to get a nice inspector tool for our application is to:

1. Get the QWebView page
2. set the QWebSettings.DeveloperExtrasEnabled attribute on this page
3. Instantiate a QWebInspector
4. Pass the view page to the inspector

Here is “loader-webinspector.py”, a new HTML loader which can show a web inspector when one presses F12:

import os import sys from PyQt4.QtCore import * from PyQt4.QtGui import * from PyQt4.QtWebKit import * from webpage import WebPage class Window(QWidget): def __init__(self): super(Window, self).__init__() self.view = QWebView(self) self.setupInspector() self.splitter = QSplitter(self) self.splitter.setOrientation(Qt.Vertical) layout = QVBoxLayout(self) layout.setMargin(0) layout.addWidget(self.splitter) self.splitter.addWidget(self.view) self.splitter.addWidget(self.webInspector) def setupInspector(self): page = self.view.page() page.settings().setAttribute(QWebSettings.DeveloperExtrasEnabled, True) self.webInspector = QWebInspector(self) self.webInspector.setPage(page) shortcut = QShortcut(self) shortcut.setKey(Qt.Key_F12) shortcut.activated.connect(self.toggleInspector) self.webInspector.setVisible(False) def toggleInspector(self): self.webInspector.setVisible(not self.webInspector.isVisible()) def main(): app = QApplication(sys.argv) window = Window() html = open(sys.argv[1]).read() window.show() window.view.setHtml(html) app.exec_() if __name__ == "__main__": main()

The four steps I described are done in the “setupInspector()” method.

And here is “console-webinspector.html”:

<html> <head> <script> function chattyFunction(arg1, arg2) { var result; result = arg1 * 2; console.log("result: %d", result); result += arg2; console.warn("result: %d", result); result /= 4; console.error("result: %d", result); return result; } </script> </head> <body> Complex computation: <script> document.write(chattyFunction(2, 3)); </script> </body> </html>

It is similar to “console-log.html” but takes advantage of two new features which do not work with the previous approach:

• printf-style formatting: that is, printing the value of result with "result: %d", result, not "result: " + result
• log categorization: you can use console.warn() and console.error() to get different type of output. These methods worked with the previous approach, but the categorization was lost.

Loading “console-webinspector.html” with “loader-webinspector.py” and pressing F12 we get this:

Closing words

These two approaches should help you track down the nastiest bugs in your embedded JavaScript code. The Web Inspector approach is probably the most powerful one, but the Python logging approach can also be useful when tracking down bugs where it is more practical to have one single log output for both the PyQt and the JavaScript sides.

I recently had the pleasure of being among the first to use the new sponsorship system in Debian.

For a non-insider (that is, someone who is not an official Debian Developer), getting a package into the Debian distribution and, by proxy, into the Ubuntu distribution requires getting the attention of someone with sufficient interest and privilege to do the actual upload. It’s called finding a sponsor in Debian parlance, and it’s sometimes a bit of a challenge.

The traditional approach for the last while is to build a source package for your software, make it available somewhere over the internet, and then post a message to the debian-mentors@lists.debian.org mailing list and hope that someone takes the bait. This is usually followed by pleads in IRC and follow-up messages to the mainling list.

Recently, a new workflow was set up in which you file a bug against the sponsorship-requests pseudopackage and hope that someone is interested. Among the advantages of this new workflow is that (a) it’s similar to other Debian workflows you need to learn when packaging software for Debian (for example, the WNPP pseudo-package) and (2) there is a place where sponsorship requests are aggregated.

It’s a fast, easy to use, and (in my experience) effective way to find a sponsor for your package in Debian. Here’s the basic workflow you need to follow.

1. State your intention by filing and ITP or ITA bug with WNPP.
2. Package your software.
3. Upload the source package to mentors.debian.net.
4. Use reportbug or send an email to submit@bugs.debian.org with a carefully formatted message — see this for an example.  There is no reportbug template available for the sponsorship-requests pseudo-package, so using your usual mail program will probably be easier for now.
5. When your new bug is confirmed, link to to your WNPP bug if necessary (and it should be necessary). The command “bts affects SRbug + src:srcpkg . block WNPPbug by SRbug” will do.
6. Sit back and wait.

This new workflow is remarkably similar to filing an upload request through Launchpad.  I assure you it’s a complete coincidence and convergent evolution at work.

I have been using Scrum for a while. Back at my previous role, we tried using Scrum within the integration team that was creating the nightly builds and our bi-weekly releases. It brought good results, the team specially liked the visibility of the task board and the daily stand-ups.

We did found a bit artificial to have a cadence. We were suppose to put out a release every two weeks but we end up doing it as often as we could (or made sense), as we were not in control of when the new software was landing in our plate.

Since then, I’ve this nagging thought that Scrum might not be appropriated to service teams or teams with a large portion of maintenance/customer support work. I have found iterations shorter than 2 weeks, can be over burden by the demo, planning and sizing overheads. In the other hand, two weeks is too much time for teams with Service Level Agreements of days or hours. It also seems a bit cumbersome for short project (~1 month), were you end up with 2 or 1 iterations… What to do!?

In Canonical several teams have used Kanban in order to improve their development processes, so I started reading up on it when I stumbled on this excellent article on Kanban vs Scrum.

The author won me over straight away by not trying to decide which of the two practices is best but instead doing a great job at remaining impartial.

Looking back at the Symbian Foundation’s integration team it seems that Kanban would have been better suited. It retains the focus on making information visible while concentrating on reducing WIP.  It seems better suited to a “specialist” team, where most members share the same skills and work on similar tasks. Scrum seems to work better for cross-discipline project teams.

Also, the emphasis on managing constant flow of work is one that resonates with teams that have a work “currency” measured in days of effort (bugs?) rather in large projects lasting months at the time.

While Scrum has been very successfully adopted by the Certification team at Canonical, My previous experience with the Integration team had stopped me from cheering on Scrum in teams that have a constant flow of work. Now, we are thinking on going Kanban! Don’t get me wrong, we are going to continue using Scrum. It is just a case of using the right tool for each job. I will keep you posted on how it goes.

If you have any advice, tips or gotchas that you could share with us, I would be most grateful if you could drop your comments here!

Time to try something new (by theonlyanla)

 

It’s sad news, yes – Ubuntu Developer Week for the 12.04 cycle is over. It’s been three fantastic days full of action-packed sessions. If you couldn’t attend, check out the logs of the sessions, all of them are posted on the UDW page.

Here’s what happened on day 3, yesterday:

1. Fixing Desktop bugs — seb128Sébastien Bacher kicked off our last day. At first he took some time to explain how the Desktop team works and how they go about fixing bugs, then he took a quite recent example and explained how to work all the individual packaging bits to fix a Desktop bug in Ubuntu. For bonus points he explained how to get Wanda the Fish working in Ubuntu.
2. Triaging Desktop bugs — om26erNext up was Omer Akram, who first gave us an update about his personal life, then quickly dived into triaging bugs. He explained all the actors involved, what to bear in mind and general things to make sure when you are reviewing bug reports. Omer, who started out by triaging bugs himself, did a great job explaining how to get involved and why it’s so important.
3. Simple Lenses with Singlet — mhall119Michael Hall, an unstoppable force throughout UDW, provided a great session about how to write lenses for Unity using Singlet. For developers who have used Python in the past, this might be an even easier (and more pythonic way) to interact with Unity and Desktop bits.
4. Building locally with pbuilder — tumbleweed
   Those of you venturing into the land of Ubuntu development will have to deal with packaging and it’s good to do it in a safe, clean and reproducible manner. Stefano Rivera explained a lot of options for doing that including some advanced features useful if you want to debug builds. Great work.
5. Writing Crisp Changelogs — coolbhavi
   Again for those of you interested in package maintenance: it’s important to document your work properly. You don’t want anybody (including yourself) having to go back in a few months or years and dive into the archaelogy of a package to understand what exactly was changed and why. Bhavani Shankar shared his experience in writing crisp changelog entries.
6. Getting started with contributing to Ubuntu Documentation — jbicha
   The Ubuntu Documentation project is of vital importance to everyone who is new to Ubuntu. Also is it a great way to get involved with Ubuntu, as Jeremy Bicha showed. He explained how to the team works generally and how to actually go and contribute improvements.
7. Adding Ubuntu One to your applications — aquarius
   If you want to allow you application to sync data to the internet, it never was easier. Stuart Langridge showed and explained some easy examples which demoed how to tie in Ubuntu One services into your app.
8. Pair Programming and Code Review in the Cloud! — kirkland
   Dustin Kirkland did an impressive live demo of how to use EC2 to do pair programming, review of code and builds. He used tmux and byobu and explained in detail how to drive the infrastructure. Unfortunately the log is a bit colourless without the live demo right next to it.
9. Syncing your app data everywhere with U1DB — aquarius
   Nothing stops Stuart Langridge when he’s on a roll. He delivered his second session all about the new Ubuntu One Database. For those of you new to the initiative: “U1DB is for syncing data — that is, something structured — to every device you want”. The session is short, has lots of good information in it and a nice example of how to work with it.
10. Automated packaging with pkgme — james_w
    James Westby gave a great introduction to the pkgme project he has been working on and it’s fantastic to see that a lot of repetitive tasks are done by a tool. It was nice to see pkgme package itself. Give it a whirl and let James know how it works out for you.
11. Fixing internationalisation bugs — kelemengabor
    Gábor Kelemen is one of the heroes of Ubuntu’s internationalisation. Keeping all packages translatable and translations in shape matters deeply to him and he gave a nice overview over how common problems can easily be resolved. Köszönöm Gábor!
12. How to fix small bugs in Ubuntu — warp10
    Andrea Colangelo took over and quickly ran us through a couple of examples of fixed bugs and explained how exactly they were fixed. By the end of the session it was clear that in a lot of cases it’s no rocket science to go and fix a bug. Grazie mille, Andrea – I hope many will find your session as encouraging as we did.
13. Problem Lifecycle in Ubuntu — cprofitt
    Charles Profitt delivered the last session of the event and explained how all teams in Ubuntu work together to go from problem to solution, involving the lifecycle of a bug report, which was a big enough topic on its own already. Throughout the session he showed how you can join each of the teams and make a difference. Awesome!

What a fantastic day. Thanks a lot to all the speakers who made this Ubuntu Developer Week possible. Thanks a lot to everyone who attended as well. It was great to see a lot of interaction, questions and interest. Until next time!

Back in September, we announced our first fastdowntime deployment. That was a new way to do deployment involving DB changes. This meannt less downtime for you the user, but we were also hoping that it would speed up our development by allowing us to deliver changes more often.

How can we evaluate if we sped up development using this change? The most important metric we look at when making this evaluation is cycle time. That’s the time it takes to go from starting to make a change to having this change live in production.  So before fastdowntime, our cycle time was about 10 days, and it is now about 9 days. So along the introduction of this new deployment process, we cut 1 day off the average, or a 10% improvement. That’s not bad.

But comparing the cumulative frequency distribution of the cycle time with the old process and the new will give us a better idea of the improvement.

On this chart, the gap between the orange (fastdowntime deployment) and blue (original process) lines shows the improvement to us.  We can see that more changes were completed sooner. For example, under the old process about 60% of the changes were completed in less than 9 days whereas about 70% were completed under the same time in the new process. It’s interesting to note that for changes that took less than 4 days to complete or that took more than 3 weeks to complete, there is no practical difference between the two distributions. We can explain that by the fact that things that were fast before are still fast, and things that takes more than 3 weeks would usually have also encountered a deployment point in the past.

That’s looking at the big picture. Looking at the overall cycle time is what gives us confidence that the process as a whole was improved. For example, the gain in deployment could have been lost by increased development time. But the closer picture is more telling.

The cycle time charted in this case is from the time a change is ready to be deployed until it’s actually live. It basically excludes the time to code, review, merge and test the changes. In this case, we can see that 95% of the changes had to wait less than 9 days to go live under the new process whereas it would take 19 days previously to get the same ratio. So an
improvement of 10 days! That’s way more nice.

Our next step on improving our cycle time is to parallelize our test suite. This is another major bottleneck in our process. In the best case, it usually takes about half a day between the time a developer submits their branch for merging until it is ready for QA on qastaging. The time in between is passed waiting and  running the test suite. It takes about 6 hours to our buildbot to validate a set of revisions. We have a project underway to run the tests in parallel. We hope to reduce the test suite time to under an hour with it. This means that it now would be possible for a developer to merge and QA a change on the same day! With this we expect to shave another day maybe two from the global cycle time.

Unfortunately, there are no easy silver bullets to make a dent in the time it takes to code a change. The only way to be faster there would be to make the Launchpad code base simpler. That’s also under way with the services oriented architecture project. But that will take some time to complete.

Photo by Martin Heigan. Licence: CC BY NC ND 2.0.