Working with virtualisation I find myself occasionally needing to generate a random MAC address for use with a virtual machine. I have a stupid little local script which spits one out, which is all fine and dandy for my purposes. However this week one of my colleagues was writing a wiki page and needed to include instructions on how to set the MAC address on the Arndale board. He wanted to include a shell snippet to generate one and I suggested that there must be websites which will generate you a suitable address. But when I came to look we found that not a single one of the half a dozen site which I looked at handled the locally administered or multicast bits correctly, meaning that they would randomly generate either multicast addresses or addresses using assigned OUI (or both). Using a random OUI may not cause too much trouble in practice but using a multicast address is sure to lead to strange behaviour, and in any case it's kind of lame. So last night I sat down and wrote a quick hack cgi script to generate random addresses and tonight I deployed it at: http://www.hellion.org.uk/cgi-bin/randmac.pl. This is where the world and his dog leaves a comment pointing me to the existing service my searches missed...

I've recently started staging upgrades from Squeeze to Wheezy. One unpleasant surprise was that the mutt-patched package available to Debian doesn't contain the "sidebar-new-only" patch. This means I need to maintain it myself again, which I'd rather avoid. Over time I've been slowly moving to standard Debian systems, trying to not carry too many local perversions around. Unfortunately if you've kept all your mail since 1994 you have many mailboxes. having mutt-patched available at all, with the sidebar patch, is a great timesaver. But I don't want to see mailboxes I'm never going to touch; just mailboxes with new mail in them. Also I find the idea of having to explicitly define mailboxes a pain. Just run inotify on ~/Maildir and discover the damn things yourself. Please computer, compute! If you divide up "mail client" into distinct steps it doesn't seem so hard:

• Show a list of folders: all, new-mail-containing only.
• Viewing a list of mail-messages: all in folder, or folders.
• Compose a new mail.
• Reply to a mail.

Obviously there is more to it than that. Sending mail? exec( sendmail ). Filtering mail? procmail/sieve/etc. Editing mail? exec(vim). I'm sure if I were to start a core of a program, suitable for myself, would be simple enough. Maybe with lua, maybe with javascript, but with a real language at the core. Anyway I've thought this before, and working with quilt and some ropy patches has always seemed like the way to go. Maybe it still is, but I can dream. (PS. Sup + Notmuch both crash on my archives. I do not wish to examine them further. Still some interesting ideas. It should be possible to say "maildirs are tags; view "~/Maildir/.livejournal.2003" and ~/Maildir/.livejournal.2007 at the same time. Why just a single directory in the "index-view? So 1994.) Disjointed posts R Us. Obquote: "How hard could it be?" -- Patrick.

I totally forgot it, but as the DPL elections are now done, we have a winner for the #DPL game. Of the (more or less) fifteen persons who participated to the game (thank you!), only four received points for having at least one of their Fantastic Four running for DPL:

• M nica Ramirez Arceda proposing Moray Allan
• Mehdi Dogguy proposing Lucas Nussbaum
• Paul Tagliamonte proposing Gergely Nagy
• Tiago Bortoletto Vaz proposing Moray Allan

As Lucas is now the new DPL, our one and only winner of the DPL game is... ... Mehdi Dogguy! Congrats!

Continuing the previous post about commits and bugs, I d like to review some mistakes I saw recently. Mistakes do happen, but mentioning them here is meant to teach others and hopefully to reduce similar ones in the future. This post isn t about shaming the authors/commiters. Also, the points I highlight are what I consider as a mistakes or problems, other people might think differently.

1. Mentioning two bugs in one commit message, which our system doesn t support right now. So the second bug doesn t get the commit notification, and that should be done manually (example: commit 2933935 and fdo#53278).
2. Referencing gerrit changes as part of the commit message (example: commit 87f185d). Giving references as part of the commit is great and helpful, but I would prefer to see the reference to the actual commit and not to its review process. This is meaningful when you search the log. If the followup change is suggested when the first change is still in review it should be combined, otherwise it already have a commit to reference.
3. Following up a commit, and not mentioning the bug it references (example: commit 87f185d). In this specific case, the we re talking about a meta bug for translating comments from German to English (fdo#39468), so no harm done. But this important when you want to cherry pick a fix for a bug to other branches and might forget the follow up commits. It s also relevant to more technical meta bugs (example: fdo#62096).
4. Referencing a mailing list which reference a commit and a bug instead of referencing them directly (commit 21fea27, fdo#60534). This bug shows very well why correct referencing is important, a commit was made to fix the bug, a follow up commit was done without proper reference, and than the first commit was reverted. No one involved in trying to fix that specific bug knew about the follow up commit as it wasn t documented anywhere.
5. Referencing bugs though full bug URL instead of the right format (example: commit e1f6dac). Also the bug is referenced in the commit in the body of the message instead of the first line (header) which is more visible.
6. Referencing non existing bugs (example: commit 3a4534b). Which got a manual notification in the bug by the comitter (fdo#33091).
7. Using shortening services URL as part of commit messages (example: commit 86f8fba). There s no way to know to what the reference is without using the service, which in this case was leading to a post on one of the projects mailing list. There isn t any problem giving the direct URL to the list s archive. It s interesting whether we should link to our URL and is it OK to use other external services who also archive our mailing lists (example: commit e83990a).

To conclude, having references in commit message is really helpful, but please reference the right resource to help people find it easily and to let our automated services parse it.
Filed under: LibreOffice

Wow, my first "Debian day" in 2013, but it's a bit of a misnomer because I didn't do any Debian work tonight. I spent some time poking at geary, Yorba's new email client which looks promising. I haven't managed to get it working much, though. Someone packaged an old version in Debian but it wouldn't work with either my home or my work IMAP/SMTP servers for various reasons. I did get a git checkout to build in March or April but that stopped working on Debian when they dropped "Precise" support (It seems they were backporting various GIR/Webkit bits and pieces into their own code and didn't want to carry that around any more). They've currently got a fundraiser going, they're aiming for $100k and (at the time of writing) need half of that with only 10 hours to go. Recently I've also been trying to fix a rockbox bug on Sansa Fuze v1 which really cripples writing onto the Fuze. The original firmware does not support microsd capacities >32G which rules it out for me. Sadly the v1 version of the Fuze is uncommon enough that I don't think this bug is getting much attention. My investigations have been limited to fairly dumb bisect-like approaches, combined with lots of writing onto a microsd card (which will probably be killed dead by all this). My initial attempts at a bisect have failed as it turns out the problem is the inverse of a regression: it bizarrely seems as if the bug was fixed in a version-branch, rather than stopped working in one, so it has never been squashed in the main branch at all. Furthermore, the commit that seems to fix the problem is a totally benign version bump, and almost certainly hasn't fixed the bug. So with sufficient further testing I'll probably just prove that this bug has never been fixed. It might be time to switch tack and look into diagnosing the bug rather than trying to side-step it. Or perhaps just spend 15 on a Sansa Clip Zip and forget all about the Fuze v1. Either way I hope someone releases a 128G microsd card this year! Every now and then I wonder whether it would make sense to package rockbox in Debian in some way. Probably not.

The Debian Edu / Skolelinux project is still going strong and made its first Wheezy based release today. This is the release announcement: New features for Debian Edu ~7.0.0 alpha0 released 2013-04-26 This is the release notes for for Debian Edu / Skolelinux ~7.0.0 edu alpha0, based on Debian with codename "Wheezy". About Debian Edu and Skolelinux Debian Edu, also known as Skolelinux, is a Linux distribution based on Debian providing an out-of-the box environment of a completely configured school network. Immediatly after installation a school server running all services needed for a school network is set up just waiting for users and machines being added via GOsa , a comfortable Web-UI. A netbooting environment is prepared using PXE, so after initial installation of the main server from CD, DVD or USB stick all other machines can be installed via the network. This is the first test release based on Wheezy (which currently is not released yet). Basically this is an updated and slightly improved version compared to the Squeeze release. Software updates

• Everything which is new in Debian Wheezy, eg:
  • Linux kernel 3.2.x
  • Desktop environments KDE "Plasma" 4.8.4, GNOME 3.4, and LXDE 4 (KDE is installed by default; to choose GNOME or LXDE: see manual.)
  • Web browser Iceweasel 10 ESR
  • LibreOffice 3.5.4
  • LTSP 5.4.2
  • GOsa 2.7.4
  • CUPS print system 1.5.3
  • Educational toolbox GCompris 12.01
  • Music creator Rosegarden 12.04
  • Image editor Gimp 2.8.2
  • Virtual universe Celestia 1.6.1
  • Virtual stargazer Stellarium 0.11.3
  • Scratch visual programming environment 1.4.0.6
  • New version of debian-installer from Debian Wheezy, see installation manual for more details.
  • Debian Wheezy includes about 37000 packages available for installation.
  • More information about Debian Wheezy 7.0 is provided in the release notes and the installation manual.

Documentation

• The (English) Debian Edu Wheezy Manual is fully translated to German, French, Italian and Danish. Partly translated versions exist for Norwegian Bokmal and Spanish.

LDAP related changes

• Slight changes to some objects and acls to have more types to choose from when adding systems in GOsa. Now systems can be of type server, workstation, printer, terminal or netdevice.

Other changes

• LTSP clients start as diskless workstation / thin client can be configured via command line argument -- or individually adding an entry in lts.conf or LDAP.
• GOsa gui: Now some options that seemed to be available, but are non functional, are greyed out (or are not clickable). Some tabs are completely hidden to the end user, others even to the GOsa admin.

Regressions

• No mass import of user account data in GOsa (ldif or csv) available yet.

No updated artwork

• Updated artwork which is visible during installation, in the login screen and as desktop wallpaper is still missing or the same as we had for our Squeeze based release.

Where to get it To download the multiarch netinstall CD release you can use

• ftp://ftp.skolelinux.org/skolelinux-cd/wheezy/
• http://ftp.skolelinux.org/skolelinux-cd/wheezy/
• rsync -avzP ftp.skolelinux.org::skolelinux-cd/wheezy/

The MD5SUM of this image is: c5e773ddafdaa4f48c409c682f598b6c The SHA1SUM of this image is: 25934fabb9b7d20235499a0a51f08ce6c54215f2 How to report bugs http://wiki.debian.org/DebianEdu/HowTo/ReportBugs

(Debian) packaging and Git. The big picture is as follows. In my view, the most natural way to work on a packaging project in version control [1] is to have an upstream branch which either tracks upstream Git/Hg/Svn, or imports of tarballs (or some combination thereof, and a Debian branch where both modifications to upstream source and commits to stuff in ./debian are added [2]. Deviations from this are mainly motivated by a desire to export source packages, a version control neutral interchange format that still preserves the distinction between upstream source and distro modifications. Of course, if you're happy with the distro modifications as one big diff, then you can stop reading now gitpkg $debian_branch $upstream_branch and you're done. The other easy case is if your changes don't touch upstream; then 3.0 (quilt) packages work nicely with ./debian in a separate tarball. So the tension is between my preferred integration style, and making source packages with changes to upstream source organized in some nice way, preferably in logical patches like, uh, commits in a version control system. At some point we may be able use some form of version control repo as a source package, but the issues with that are for another blog post. At the moment then we are stuck with trying bridge the gap between a git repository and a 3.0 (quilt) source package. If you don't know the details of Debian packaging, just imagine a patch series like you would generate with git format-patch or apply with (surprise) quilt. From Git to Quilt. The most obvious (and the most common) way to bridge the gap between git and quilt is to export patches manually (or using a helper like gbp-pq) and commit them to the packaging repository. This has the advantage of not forcing anyone to use git or specialized helpers to collaborate on the package. On the other hand it's quite far from the vision of using git (or your favourite VCS) to do the integration that I started with. The next level of sophistication is to maintain a branch of upstream-modifying commits. Roughly speaking, this is the approach taken by git-dpm, by gitpkg, and with some additional friction from manually importing and exporting the patches, by gbp-pq. There are some issues with rebasing a branch of patches, mainly it seems to rely on one person at a time working on the patch branch, and it forces the use of specialized tools or workflows. Nonetheless, both git-dpm and gitpkg support this mode of working reasonably well [3]. Lately I've been working on exporting patches from (an immutable) git history. My initial experiments with marking commits with git notes more or less worked [4]. I put this on the back-burner for two reasons, first sharing git notes is still not very well supported by git itself [5], and second Gitpkg maintainer Ron Lee convinced me to automagically pick out what patches to export. Ron's motivation (as I understand it) is to have tools which work on any git repository without extra metadata in the form of notes. Linearizing History on the fly. After a few iterations, I arrived at the following specification.

• The user supplies two refs upstream and head. upstream should be suitable for export as a .orig.tar.gz file [6], and it should be an ancestor of head.
• At source package build time, we want to construct a series of patches that
  1. Is guaranteed to apply to upstream
  2. Produces the same work tree as head, outside ./debian
  3. Does not touch ./debian
  4. As much as possible, matches the git history from upstream to head.

Condition (4) suggests we want something roughly like git format-patch upstream..head, removing those patches which are only about Debian packaging. Because of (3), we have to be a bit careful about commits that touch upstream and ./debian. We also want to avoid outputting patches that have been applied (or worse partially applied) upstream. git patch-id can help identify cherry-picked patches, but not partial application. Eventually I arrived at the following strategy.

1. Use git-filter-branch to construct a copy of the history upstream..head with ./debian (and for technical reasons .pc) excised.
2. Filter these commits to remove e.g. those that are present exactly upstream, or those that introduces no changes, or changes unrepresentable in a patch.
3. Try to revert the remaining commits, in reverse order. The idea here is twofold. First, a patch that occurs twice in history because of merging will only revert the most recent one, allowing earlier copies to be skipped. Second, the state of the temporary branch after all successful reverts represents the difference from upstream not accounted for by any patch.
4. Generate a "fixup patch" accounting for any remaining differences, to be applied before any if the "nice" patches.
5. Cherry-pick each "nice" patch on top of the fixup patch, to ensure we have a linear history that can be exported to quilt. If any of these cherry-picks fail, abort the export.

Yep, it seems over-complicated to me too. TL;DR: Show me the code. You can clone my current version from

git://pivot.cs.unb.ca/gitpkg.git

This provides a script "git-debcherry" which does the history linearization discussed above. In order to test out how/if this works in your repository, you could run

git-debcherry --stat $UPSTREAM

For actual use, you probably want to use something like

git-debcherry -o debian/patches

There is a hook in hooks/debcherry-deb-export-hook that does this at source package export time. I'm aware this is not that fast; it does several expensive operations. On the other hand, you know what Don Knuth says about premature optimization, so I'm more interested in reports of when it does and doesn't work. In addition to crashing, generating multi-megabyte "fixup patch" probably counts as failure. Notes

1. This first part doesn't seem too Debian or git specific to me, but I don't know much concrete about other packaging workflows or other version control systems.
2. Another variation is to have a patched upstream branch and merge that into the Debian packaging branch. The trade-off here that you can simplify the patch export process a bit, but the repo needs to have taken this disciplined approach from the beginning.
3. git-dpm merges the patched upstream into the Debian branch. This makes the history a bit messier, but seems to be more robust. I've been thinking about trying this out (semi-manually) for gitpkg.
4. See e.g. exporting. Although I did not then know the many surprising and horrible things people do in packaging histories, so it probably didn't work as well as I thought it did.
5. It's doable, but one ends up spending about a bunch lines of code on duplicating basic git functionality; e.g. there is no real support for tags of notes.
6. Since as far as I know quilt has no way of deleting files except to list the content, this means in particular exporting upstream should yield a DFSG Free source tree.

Last week was the OpenStack Design Summit in Portland, OR where we, developers, discussed and designed the new OpenStack release (Havana) coming up. The summit has been wonderful. It was my first OpenStack design summit -- even more as a PTL -- and bumping into various people I've never met so far and worked with online only was a real pleasure! <figure> <figcaption>Me and Nick ready to talk about Ceilometer new features.</figcaption> </figure> Nick Barcet from eNovance, our dear previous Ceilometer PTL, and myself, talked about Ceilometer and presented the work that bas been done for Grizzly, with some previews of what we'll like to see done for its Havana release. You can take a look at the slides if you're curious. Design sessions Ceilometer had his design sessions during the last days of the summit. We noted a lot of things and commented during the sessions in our Etherpads instances. The first session was a description of Ceilometer core architecture for interested people, and was a wonderful success considering that the room was packed. Our Doug Hellmann did a wonderful job introducing people to Ceilometer and answering question. <figure> <figcaption>Doug explaining Ceilometer architecture.</figcaption> </figure> The next session was about getting feedbacks from our users. We had a lot of surprise to discover wonderful real use-cases and deployments, like the CERN using Ceilometer and generating 2 GB of data per day! The following sessions ran on Thursday and were much more about new features discussion. A lot ot already existing blueprints were discussed and quickly validated during the first morning session. Then, Sandy Walsh introduced the architecture they use inside StackTach, so we can start thinking about getting things from it into Ceilometer. API improvements were discussed without surprises and with a good consensus on what needs to be done. The four following sessions that occupied a lot of the days were related to alarming. All were lead by Eoghan Glynn, from RedHat, who did an amazing job presenting the possible architectures with theirs pros and cons. Actually, all we had to do was to nod to his designs and acknowledge the plan on how to build this. That last two sessions were about discussing advanced models for billing where we got some interesting feedback from Daniel Dyer from HP, and then were a quick follow-up of the StackTach presentation from the morning session. Havana roadmap The list of blueprints targetting Havana is available and should be finished by next week. If you want to propose blueprints, you're free to do so and inform us about it so we can validate it. The same applies if you wish to implement one of them! API extension I do think the API version 2 is going to be heavily extended during this release cycle. We need more feature, like the group-by functionnality. Healthnmon In parallel of the design sessions, discussions took place in the unconference room with the Healthnmon developers to figure out a plan in order to merge some of their efforts into Ceilometer. They should provide a component to help Ceilometer supports more hypervisors than it currently does. Alarming Alarming is definitely going to be the next big project for Ceilometer. Today, Eoghan and I started building blueprints on alarming, centralized in a general blueprint. We know this is going to happen for real and very soon, thanks to the engagements of eNovance and RedHat who are commiting resources to this amazing project!

Online tech news site Ars Technica (which I recommend, by the way) recently reviewed the Dell XPS 13 Developer Edition. Its unique feature: it ships with Ubuntu Linux as the default operating system. This preload deal had a few unique properties:

• It s from a major system vendor, not a no-name or third-party integrator.
• It s a desktop-oriented product, not a server.
• Most notably, the vendor actually put effort into making it work well.

That last point deserves some explanation. A few vendors have grabbed a Windows computer they sell and allowed the option to preload Linux on it, but without support; you re on your own if it doesn t work in some way, which is likely. Essentially, they save you the time of wiping Windows off the box and doing a fresh install, but not much more. But this laptop comes out of Dell s Project Sputnik, a project to put out Linux machines for developers with a DevOps flavor, and they felt the machine had to work as well as their regular products. So they actually put effort and testing into getting the laptop to run Ubuntu well, with all the drivers configured properly and tweaked to support the machine s quirks, just like they do for Windows. And so, the review is surprised to learn that Ubuntu on the XPS 13, well, just works! It s even in the title of the review. Here s reviewer Lee Hutchinson s observations:

I ve struggled before with using Linux as my full-time operating environment both at work and at home. I did it for years at work, but it was never quite as easy as I wanted it to be on an older Dell laptop, keeping dual monitor support working correctly across updates required endless fiddling with xorg.conf, and whether or not it was Nvidia s fault was totally irrelevant to swearing, cursing Past Lee, trying desperately to get his monitors to display images so he could make his 10am conference call without having to resort to running the meeting on the small laptop screen.

And thence comes the astonishment: on this Linux laptop, everything just works. Most of the review is spent on the kinds of hardware features that distinguish this from other laptops: the keyboard is like this, the screen is that resolution, it has this CPU and this much RAM and so on. Some space is devoted to impressions of the default Ubuntu 12.04 install, and some space is given to the special DevOps software, which helps the developer reproduce the software environment on the laptop when deploying apps. But before all that, Hutchinson has to put in a dig:

It s an impressive achievement, and it s also a sad comment on the overall viability of Linux as a consumer-facing operating system for normal people. I don t think anyone is arguing that Linux hasn t earned its place in the data center it most certainly has but there s no way I d feel comfy installing even newbie-friendly Ubuntu or Mint on my parents computers. The XPS 13 DE shows the level of functionality and polish possible with extra effort, and that effort and polish together means this kind of Linux integration is something we won t see very often outside of boutique OEMs.

Of course, Windows is actually worse than Linux on the hardware front when you don t get it pre-installed. Imagine if more vendors put as much effort into preinstalled Linux as they did into preinstalled Windows. In that alternate reality, I imagine people would react more like this:

Isn t that what you re looking for in a mainstream product? Rick chided. In 1996 it was: Wow look at this, I got Linux running on xxxxxxxx. Even in 2006 that was at times an accomplishment When was the last time you turned on an Apple or Windows machine and marveled that it just worked? It should be boring.

Which was, of course, the reaction Hutchinson got when discussing the review with a Linux-using friend. With Microsoft being less of a friend to the hardware vendors every day, here s a case study more of them should be paying attention to.

Neil McGovern, on behalf of the Debian Release Team, announced the target date of the weekend of 4th/5th May for the release of Debian 7.0 "Wheezy". Now it's time to organize some Wheezy release parties to celebrate the event and show all your Debian love!

By now, Debian ships quite a lot of Haskell packages (~600). Because of GHC's ABI volatility, whenever we upload a new version of a library, we have to rebuild all libraries that depend on that. In particular, if we upload a new version of the compiler itself, we have to rebuild all Haskell library packages. So we have to rebuild stuff a lot. Luckily, Debian has a decent autobuilding setup so that I just need to tell it what to rebuild, and the rest happens automatically (including figuring out the actual order to build things).
I was curious how much we use the buildd system compared to other packages, and also how long the builders are busy building Haskell packages. All the data is in a postgresql database on buildd.debian.org, so with some python and javascript code, I can visualize this. The graphs show the number of all uploads by autobuilder on the amd64 architecture, with haskell uploads specially marked, and the second graph does the same for the build time. You can select time ranges and get aggregate statistics for that time span. During the last four days a complete rebuild was happening, due to the upload of GHC 7.6.3. During these 2 days and 18 hours building 537 packages took 48 hours of build time and produced 15kg of CO₂. That is 94% of all uploads and 91% the total build time. The numbers are lower for the whole of last year: 52% of uploads, 31% of build time and 57kg of CO₂. (The CO₂ numbers are very rough estimates.)
Note that amd64 is a bit special, as most packages are uploaded on this architecture by the developers, so no automatic builds are happening. On other architectures have, every upload of a (arch:any) package is built, so the share of Haskell packages will be lower. Unfortunately, at the moment the database does not provide me with a table across all architectures (and I was too lazy to make it configurable yet).

The first Qt 5 packages have been accepted in Debian experimental.

What's there

• qtbase-opensource-src: lib[concurrent core dbus gui network opengl printsupport sql test widgets xml], examples, development packages and debug symbols.
• qttools-opensource-src: lib[qtlucene designer help], qdbus, development headers and debugging symbols.
• qtjsbackend-opensource-src: libqt5v8-5
• qtxmlpatterns-opensource-src
• qtchooser, which allows to select between Qt4 or Qt5 at build time.

What's not there

In October I announced that starting with 3.6 kernel it was eventually safe to unplug Zenbook.
Then in bugreport I was told that Sentelic touchpad driver was included in 3.8 kernel.
And guess what I don t have to patch kernel to have working touchpad using 3.8 kernels but I have to worry about unplugging laptop cause with 3.8.x kernel it s quite common that it turns laptop off again.
So the question is do we have any regression tests in kernel?
Should I test every kernel release between 3.8.5 and 3.6.0 to find the one that incorporated that bug again?

The Debian project distributes software packages via its archive, propagated through a network of mirrors. This archive is organised in three areas, main, that contains the Debian system, and contrib and non-free, that contain accessory packages that are not Free. The packages in non-free contain files that have a proprietary license. The source packages in contrib contain only Free files, but produce binary packages that are either useless without the access to remote services, or contain non-Free files, or cause the installation of non-Free materials. The contrib area is an endless source of discussions, as it is not always easy to draw the line between what is usable and what is useless without remote services. I wonder if it would be better to replace the contrib area by a new priority level, remote , lower than extra. Packages that are entirely Free (source and binary) and that do not cause the installation of proprietary software would be fit for main. For the packages that can not function without non-Free software, given that the work to be done to free them is the same regardless whether the proprietary code is included in the source package (in non-free) or not (in contrib), I think that in both cases the package should be in non-free as it is not Free in practice. This would allow for a simple criterion: does the selection of a binary package trigger the installation of non-Free files? If yes, the package and its source belong to non-free. If not, they belong to main. Then, if they need to access a remote service that would not be possible to set up on a network where only Debian is available, their priority would be remote.

Michael Stapelberg recently posted a blog post about looking into the number of Debian Developers actively working on RC bugs for the upcoming wheezy release. In this blog post I analyze the data shared by Michael and provide the R commands used to generate the plots & findings. If you are interested into looking into the data yourself, but don t like R, I suggest using ipython notebook + numpy instead.

Analysis After parsing the data file we typically want to get an understanding of the data, by using summary(bugs) we get the minimum(1), median(5), mean(15.4), max(716) and quantiles of the data. This shows that the number of messages is wide-spread and a few people contribute a lot. To visualize the dispersion of the data we can create a box plot showing the range of messages: As the first and third quantile are close together we can assume that the majority of the work is done by a few, especially since the second quantile is 5. This is supported by the histogram below, where the x axis is the number of recorded messages and y is the number of developers.

Top 10 contributors The TOP 10 contributors, according to the dataset, are:

1. Lucas Nussbaum - 716 messages
2. Gregor Herrmann - 270 messages
2. Jakub Wilk - 270 messages
4. Andreas Beckmann - 225 messages
5. Julien Cristau - 205 messages
6. Cyril Brulebois - 169 messages
7. Moritz Muehlenhoff - 162 messages
8. Michael Biebl - 159 messages
9. Salvatore Bonaccorso - 158 messages
10. Christoph Egger - 142 messages

r commands These are the commands used to generate the plots and information in this plot:

bugs <- read.csv("by-msg.csv")
summary(bugs)
boxplot(bugs$rcbugmsg, log='y', range=0, ylab="# bugs")
quantile(bugs$rcbugmsg)
0%  25%  50%  75% 100%
1    2    5   12  716
# create histogram
llibrary('ggplot2')
ggplot(bugs, aes(x=rcbugmsg)) + geom_histogram(binwidth=.5, colour="black", fill="black") + scale_x_sqrt()
top10 <- tail(bugs[order(bugs$rcbugmsg),], 10)
top10

Michael Stapelberg recently posted a blog post about looking into the number of Debian Developers actively working on RC bugs for the upcoming wheezy release. In this blog post I analyze the data shared by Michael and provide the R commands used to generate the plots & findings. If you are interested into looking into the data yourself, but don t like R, I suggest using ipython notebook + numpy instead.

Analysis After parsing the data file we typically want to get an understanding of the data, by using summary(bugs) we get the minimum(1), median(5), mean(15.4), max(716) and quantiles of the data. This shows that the number of messages is wide-spread and a few people contribute a lot. To visualize the dispersion of the data we can create a box plot showing the range of messages: As the first and third quantile are close together we can assume that the majority of the work is done by a few, especially since the second quantile is 5. This is supported by the histogram below, where the x axis is the number of recorded messages and y is the number of developers.

Top 10 contributors The TOP 10 contributors, according to the dataset, are:

1. Lucas Nussbaum - 716 messages
2. Gregor Herrmann - 270 messages
2. Jakub Wilk - 270 messages
4. Andreas Beckmann - 225 messages
5. Julien Cristau - 205 messages
6. Cyril Brulebois - 169 messages
7. Moritz Muehlenhoff - 162 messages
8. Michael Biebl - 159 messages
9. Salvatore Bonaccorso - 158 messages
10. Christoph Egger - 142 messages

r commands These are the commands used to generate the plots and information in this plot:

bugs <- read.csv("by-msg.csv")
summary(bugs)
boxplot(bugs$rcbugmsg, log='y', range=0, ylab="# bugs")
quantile(bugs$rcbugmsg)
0%  25%  50%  75% 100%
1    2    5   12  716
# create histogram
llibrary('ggplot2')
ggplot(bugs, aes(x=rcbugmsg)) + geom_histogram(binwidth=.5, colour="black", fill="black") + scale_x_sqrt()
top10 <- tail(bugs[order(bugs$rcbugmsg),], 10)
top10