Mike Hommey, our Iceweasel maintainer
For as long as I have known Mike, he s been maintaining one of the largest (and most widely used) package: Iceweasel, Debian s default web browser. It s effectively Mozilla s Firefox although it has been renamed to avoid some rules enforced by Mozilla s trademark policy. But we might see Firefox back in Debian read on to know Mike s plans.
His story is also very interesting in that he went from simple user to Iceweasel maintainer, and now he s working for Mozilla Corporation. But you already knew that contributing to free software is a good way to grow skills and gain experience that are valuable on the job market, right?
My questions are in bold, the rest is by Mike.
Who are you?
I am Mike Hommey. I am French, even if my name doesn t sound so.
I have been a GNU/Linux user since 1995, using Debian since 1999, and
started packaging in 2003. After a long time in the
NM queue, I became
a
DD in 2005.
The main reason I started being actively involved is quite selfish: I
wanted some things done, and I just did them. My first packages were
extensions for the Mozilla Suite, the old one that directly inherited
from Netscape Communicator. Later on, I wanted some of these extensions
to work with the new kid on the block: Phoenix; or maybe it was already
Firebird. By then, integrating extensions was a hassle, and the
mozilla-browser maintainer had come up with a script that would make it
easier for extension packages. So I ported that script for use with
Phoenix/Firebird and sent it to the BTS.
Then Phoenix/Firebird became Firefox, and it grew a real extension
manager. Except that is was entirely not suited for extensions installed
by the packaging system. So I made it work better. And made a few more
changes to make Firefox work better. All through patches or NMUs.
Then I became co-maintainer, then Firefox couldn t keep its name and
became Iceweasel, and, fast-forward until today, I m now taking care of
Iceweasel/Xulrunner and Iceape in stable, unstable, experimental and
an
external repository.
This 8 years-long story (wow, I hadn t even realized it had been that
long until I wrote it) tells you something: newcomers shouldn t be
afraid to stick their hands anywhere, even in big packages. I was only a
Mozilla and Phoenix end-user when I started.
Apart from Mozilla-related packaging, I also happen to (co-)maintain
some other packages in Debian, most notably webkit, though I haven t
been very active in the pkg-webkit team recently. There are several
reasons for that, the main one being that there are other team members
getting the job done. And I can t say that much about the pkg-mozilla
team, since there are effectively no other team members.
What s your biggest achievement within Debian?
I am quite proud that Squeeze will be the first Debian release where
Iceweasel works on all supported architectures. Previously, we only knew
the package compiled on all these architectures. Starting with Squeeze,
we know it passes several of the test suites coming with the source
code. This ensures most of the browser is functional. It was actually
far from being the case before, as it appeared when the test suites
were first enabled.
I think it is very important to have properly working packages on all
our supported architectures. The current evolution of hardware shows
how important it still is. Who would have thought a few years back that
we would see ARM or MIPS based netbooks today ?
What are your plans for Debian Wheezy?
For Debian Wheezy, I would like to improve Iceweasel/Icedove/Iceape
integration with the packaging system. Something that would allow to
use the apt database to find extensions or plugins, on top of the
current behaviour. I also want to improve desktop integration, most
notably for KDE.
Another thing I d like to see happen is to package google breakpad
independently (its source code is currently embedded in chromium and
iceweasel, though not built, as far as I know), and have our Mozilla
products builds be able to send their crash reports upstream. It is very
important that upstream gets direct visibility over what crashes on
GNU/Linux systems. It helps making them aware of issues that would
otherwise probably remain unnoticed, as there are much more users
using distributions packages than upstream tarballs. And not all Debian
users report crashes to the
BTS. I know at least Fedora and SuSE are
already doing it.
More importantly, I want to avoid the sad situation we got with Squeeze,
where we re going to release a 18 months old Iceweasel. We got there for
a combination of reasons, one being that I was preparing for a freeze in
December 2009 and focusing on getting 3.5 in shape instead of the then
upcoming 3.6.
The result was that we didn t get 3.6 packages before upstream released
3.6.3 in April 2010. By then it was too late, considering the
uncertainty of the release schedule, to update reverse dependencies and
get 3.6 ready for Squeeze.
Things are different for 4.0. I m already getting ahead of things, and
while reverse dependencies haven t been taken care of, all beta releases
have been made available through
http://mozilla.debian.net/, usually
within hours after upstream release (sometimes even a few hours before
official announcement, but always after availability on ftp.mozilla.org).
A great share of our patches were also pushed upstream.
Several things made that possible:
- I m now closely following upstream trunk
- I m starting to prepare packages when candidate builds are distributed
upstream, which usually happens a few days ahead for betas, and more
than a week ahead for stable releases.
- I automated part of the package building process, and have a beefy
build machine. I m getting near being able to provide nightly builds
of upstream trunk.
There will be a couple major upstream releases until Wheezy comes along,
and I want to make them available early in unstable, even if that means
breaking reverse dependencies until they are fixed.
Finally, I would like to get other people involved, starting with the
Icedove maintainer. Volunteers are very much welcome, for any kind of
involvement: bug triaging, documentation (which we are deeply lacking),
testing, code People interested can contact the
pkg-mozilla team list.
As the Debian packaging gets less time consuming, I should be able to
spend more time mentoring, which should help.
If you could spend all your time on Debian, what would you work on?
I actually have been working almost full time on Debian for a few months
during a more-or-less purposeful unemployment period. That s when I
attempted to add an alert popup when Iceweasel or extensions are
upgraded (which was eventually removed because not working very
effectively). That s when I worked on Iceweasel 3.6 and the first 4.0
betas. That s when I pushed more than 70 patches upstream, and got
upstream commit access.
I know for a fact that keeping up with upstream and answering bug
reports is already time consuming, and time comes in finite quantity.
Working full time on Debian allows to do more than that, as I ve been
able to experience first hand. Unfortunately, that doesn t help pay the
bills, so it would be best if time could be shared with other persons.
Like, actual members in the pkg-mozilla team.
Anyways, if I were to work full time on Debian again, I d like to do
more than packaging, and help improve some of our infrastructure, most
notably the buildd network, to grow some automated way to get packages
built on all or some of our architectures. Call that PPA if you want,
though I don t think we need something exactly like PPA.
We sure do have porter boxes, but there is a huge overhead to get
packages built there: you need to first try, then see you lack build
dependencies, then wait for admins to install them, then come back and
launch your build, and finally come back again much later to see how
it went. And that s when it goes smoothly. Repeat for each architecture.
It s already cumbersome when it s a small package, so imagine when it s
Iceweasel. I d like to be able to push a (signed) .dsc somewhere, say I
want it built on that and that architecture, and get binary packages and
logs back. It could then be up to developers to distribute them, or not.
Sometimes, you re just interested in test suite results.
Another related wish would be a way to access build trees of failed
builds, possibly on the buildd where it failed.
What s the biggest problem of Debian?
Lack of contributors, lack of contributors, and lack of contributors.
It can sound weird to say that in a community of 1000+ people. But the
sad reality is that we ve seen, repeatedly, calls for help in various
places from various understaffed teams (most often of effectively one
member) for years. So there is obviously a problem getting people to
invest time in these teams either on the long term, or at all.
I know this is not a very significant metric, but it already should say
a lot: I wouldn t be surprised if more than 2/3 of the number of source
lines of code in Debian come from less than 5% of the number of packages
in the archive, and see less than 5% of the DD/DM population involved.
If someone feels like doing the actual math, I m curious to know how far
I m from reality, and in what direction.
We also lack manpower to be able to make our release development
smoother. In a perfect world where manpower is not a scarce resource, we
should work on $release+1 when $release is being frozen. Said otherwise,
we should have been able to start working on Wheezy in August 2010, or
even earlier.
You ve been working for Mozilla Corporation for a few months. How does the work look like and what are you working on?
I am actually not working full time for MoCo; I am only contracting for
4 days a week. That was a request I made to keep having enough spare
time for Debian or other activities. I am working from home, and am
pretty much free about when I work, as long as I work long enough.
I take advantage of this freedom and the saved commuting time to live a
healthier life by doing some sports in the daytime (which also happens to
be cheaper).
I mostly work with Taras Glek and other people on various aspects of
Firefox startup performance. This involves pretty interesting low-level
stuff, in which I actually got involved before being contracted. This
work has nothing to do with packaging Iceweasel, though I can have a
few opportunities to do things somehow related.
You told in your blog that you were discussing with Mozilla how Debian could use the Firefox trademark. Can you tell us a bit about the progress you made?
I have got an informal approval of the patches we are applying to the
Iceweasel 4.0 beta packages. There are a few concerns about using the
system cairo library, and the embedded copy of libpng needs to be used
to have support for the animated PNGs that are used in the user
interface and that are required in Firefox feature-set. Other than
that, there are pretty much no objection on the technical side.
We managed to get to some common ground as to how to manage stable
updates and more generally, changes to our packages, but I m still
waiting for an actual agreement draft. While I, as the maintainer, am
fine with the way it should look according to my discussions with the
people involved at Mozilla, I ll seek review from my fellow Debian
Developers when I ll have something to show.
I haven t decided yet how this will reflect on the Debian packages,
though. For example, would Iceweasel stay? But I do hope Wheezy will
get Firefox back.
Is there someone in Debian that you admire for their contributions?
Not someone, but all past, present and future release team members. This
is a team that receives a lot of critics (and I indirectly gave one a
few paragraphs ago), yet manages to keep doing an amazing job and its
members are very committed to their task. I admire their dedication.
Thank you to Mike for the time spent answering my questions. I hope you enjoyed reading his answers as I did.
Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on
Identi.ca,
Twitter and
Facebook.
8 comments Liked this article? Click here. My blog is Flattr-enabled.
Now that maintain several dozens of packages in Debian, I think twice before
uploading a new one. Does it have a future, a public ? Some of the packages
I prepare are available on git.debian.org, and are
listed in Debian Med's
tasks pages. It would not
take me long to finish most of them, but that does not take into account the
time others will spend on it. They will make our archive bigger and our
quality tests longer to execute. Somebody will translate their
description. Somebody else will perhaps write a security patch someday, or a
patch to make the package compilable with a new version of GCC. All in all,
each package has a footprint in Debian's ecosystem.
That footprint starts early, as soon as the package is sent to the NEW queue. For instance, I kept by mistake some old content in the copyright file of 
Here comes the forth Debian XSF News issue! I usually try to keep
the items sorted chronologically (but grouped by topic when possible),
so if you re wondering about the current status of 
Squeeze was released this weekend and it's time to slowly migrate servers to it. The first to upgrade came the ones backing up 
The last weeks before a Debian release are usually boring with respect to working on new stuff since unstable is pretty much closed to development. Now that the release is finished, this fun is back \o/
I have been in an upload frenzy since yesterday night and I have updated some packages in unstable: KOffice[1] and KOffice-l10n 2.3.1, yakuake, rsibreak and tintin++. Another of my packages, kid3, got magically updated itself in unstable before I had time to look at it, the magic of having active co-maintainers.
[1] Thanks for the gentle push to update this, Pino :)
I also emailed one of my upstream maintainers to ask him about the KDE 4 version of his application and he will likely make a release soon. One of the goals for wheezy is remove completely KDE 3 and Qt 3. If you are maintaining a KDE 3 or Qt 3 based application, we are about to start annoying you about this! See 
Wow, that was a night. I'm still quite tired from the weekend. Someone
told me, that ~ 1 000 people subscribed to our live denting via
It's been 
Felipe Ortega, who has provided many of these statistics, has 
Although the graphs above do not say anything directly about the most
active core contributors to Wikipedia, the fact that Wikipedia is
being maintained by a tiny -- and shrinking -- proportion of its
readership does mean that the idea behind Wikipedia is under threat.
Although none are as big as Wikipedia, there are lots of good
encyclopedias out there. The reason Wikipedia is different,
interesting, and important is because -- unlike all those others --
Wikipedia is the encyclopedia that anyone can edit. Wikipedia is
powerful because it allow its users to transcend their role as
consumers of the information they use to understand the
world. Wikipedia allows users to define the reference works that
define their understanding of the their environment and each other.
But 99.98% of the time, readers do not transcend that role. I think
that's a problem. Worse, that the number is growing.
The Wikimedia Foundation recently ran a major successful effort to
attract donations in its annual fundraiser. Jimmy Wales' smiling mug
is apparently enough in the way of motivation to get something like 1%
of its readers to donate money to support the project. I think that's
very good news. If the Wikimedia community can entice even half of
those people to contribute through an 
I can't believe I didn't notice that swirl sooner. It will join my
picture of the 
Somewhat motivated by Geoff Huston's keynote at linux.conf.au 2011, I've
decided to pull my finger out and make a foray into IPv6. My 
