A Mozilla and Open Source success story
December 14, 2011
There are many success stories like this in open source, but this is such a neat one, I have to call it out. It basically goes like this:
Webdev makes awesome app (I have seen it. It’s is truly awesome. For any app, really, but *especially* for a web app). But awesome app is not as awesome as it could be in places. Webdev investigates. Finds a bottleneck in Firefox. Files bug. Goes through the seven circles of hell (XPCOM). Submits a patch. Goes through several review iterations. Patch gets committed.
Bobby Holley tells the whole story in his blog post. It’s short and worth a read.
This contribution is a testament to open source and Mozilla’s open development style. I wish we had more contributions like this (duh), but you’re probably not surprised to hear that this is pretty rare. Sure, it has to do with the level of complexity of some of the code. But, there are tons of relatively easy-to-approach parts in Firefox.
So I ask, have you ever come across a bug in Firefox that you really wanted to fix but didn’t/couldn’t? If so, what stopped you and what could perhaps have helped you?
December 14, 2011 at 5:32 am
Well, the problem for me is almost always that the only qualified reviewer is either massively backlogged, AWOL, or both. Here are some instructive cases:
629500/693230/702678: need love from someone who knows Windows GUI programming.
234856/235230/643041: XPCOM interface incorrectly declared as producing an ISO-8859-1 string instead of an UTF-8 string. Still open seven years later because bsmith wants to make other IID-bumping changes to nsIX509Cert at the same time. No word since August.
536192: NSPR maintainer refused to fix a type safety bug, claiming backward incompatibility.
December 14, 2011 at 7:19 am
Review turn-around time is definitely an issue sometimes. I think we should have a process for when a review is not acted upon in a certain time frame, or when an r- is not followed up by a new patch. In both cases deferring to other module peers or owners seems like a good idea to me.
See also Taras’s post on this topic: http://blog.mozilla.com/tglek/2011/12/05/24-hour-reviews/
December 14, 2011 at 7:03 am
zwol: there will be movement on those bugs (629500/693230/702678: ) shortly! jwein will be kicking ass on those as soon as he gets builds going.
December 14, 2011 at 7:35 pm
I’m only 17 years old, but for a while, I’ve wanted to fix simple CSS bugs. I once tried doing it and I downloaded all the tools like Visual C++ Express, Mozilla Build, etc. But when I tried to open up the Mercurial CLI app, it kept closing immediately. I didn’t know where to go to get help, so I gave up.
December 14, 2011 at 8:08 pm
Hey Josh! The build toolchain is quite a bit of a beast. Thanks for trying to get this far, though! Most of the Mozilla community hangs out on IRC chat where they can answer questions like these. Have a look here: https://wiki.mozilla.org/IRC. Your questions are probably best answered in the #developers channel.
December 14, 2011 at 10:28 pm
Thanks. I’ll try asking there when I’m ready to give it another go.
December 14, 2011 at 11:43 pm
In addition to what philikon said, for problems strictly about Mercurial there are also the Mercurial site, http://mercurial.selenic.com/ , the Mercurial Guide, http://mercurial.selenic.com/guide/ , and the Mercurial mailing list, http://selenic.com/mailman/listinfo/mercurial
December 14, 2011 at 11:24 pm
I once filed a Bugzilla issue for a bug that annoyed me, and that I was willing and eager to fix. All I wanted was acknowledgement that a sufficiently-good patch would in fact be accepted into the tree.
Over a year later, my bug was still “unconfirmed” with no responses. I stopped waiting, and ended up working around my problem with some third-party software. That bug remains in Firefox to this day, where it still occasionally bites me and others.
December 14, 2011 at 11:36 pm
I agree that the sheer number of unconfirmed bugs we have lingering around isn’t good. Some teams to regular triage, but not enough do. We often rely on contributors to do a lot of the triage because some components have so many. I think *any* response, even if it’s an INVALID/INCOMPLETE/WONTFIX would be better than nothing…
That said, I’m curious whether you tried rounding up a patch at all? Seems like if the bug is sufficiently annoying, waiting for somebody to confirm the bug seems like a pretty lame excuse
. Also, a bug with a patch will always get more attention, even if it’s just a work in progress… Out of curiosity, what’s the bug number?