The other day I was reading a tweet from Neil deGrasse Tyson, and it got me thinking… If you were going to cut a circle into three equal pieces using only two cuts, what would the angle to cut them be? (Θ in the diagram over on the right side there.) So I asked on Twitter, and eventually got a reply. This is my attempt to reconstruct the reasoning behind the answer.

The easiest way to figure this out, I believe, is to cut the circle in half, and then figure out what line divides the semicircle into a 2/3rds to 1/3rd ratio. So let’s do that, and label the points A, B, C, and O (for the origin), as shown on the left. We’ll also label the angle AOB as ɣ, because we'll be using it a little more later.

We know from this page that the area of a segment is r² × (ɣ - sin ɣ) / 2, and we want the segment formed by the line AB to contain 1/3rd of the total circle (or 1/3 × π × r²). Putting those together gives us the equation:
r² × (ɣ - sin ɣ) / 2 = π × r² / 3
multiplying both sides by 2, and diving both sides by r², we get
(ɣ - sin ɣ) = 2 × π / 3
Now all we have to do is simply solve for ɣ to get:
ɣ = 2.60533

That means that the angle BOC is π - ɣ, or 0.53626 radians (or 30.7º). Now, the inscribed angle is half the central angle, so in theory, to get the angle BAD, I should divide that by two, but then I’ll just need to multiply it by two again to account for the other half of the circle, so let’s skip all that, and just call it 30.7º.

Much of the new work I’m doing these days is being stored in git repositories. Now, I’m not the biggest fan of git, particularly its UI, but the advantages of GitHub and GitX are hard to ignore. Despite that, I still really missed being able to type hg out to see which patches I would be pushing, so, after a short chat with (and demo from) Ben, I came up with the following:

Somewhere in your path, add a file named git-outgoing which contains the following contents:

# !/bin/sh
# Uh, there shouldn’t be a space between the # and ! in the previous
# line, but the highlighter I’m using seems to require it…
git push --dry-run $1 2>&1 | awk '/^ / {print $1}' | xargs git log

(Make sure it’s executable by whomever needs to use it!)

Then, in your git config, add the following section:

[alias]
    out = outgoing

And finally, you should be able to type git out, and see something like:

commit 7d4c9b89a4663a07bed030669bae2d3c73ec78dc
Author: Blake Winton <bwinton@latte.ca>
Date:   Thu Dec 8 12:22:41 2011 -0500

    Blear 2

commit a4e8c6627bc26d7371fb2614a1c47aaf694957bd
Author: Blake Winton <bwinton@latte.ca>
Date:   Thu Dec 8 12:18:04 2011 -0500

    Bleah.

So, hopefully some of the rest of you will find this helpful, too, and if you know of a better way to do this, please let me know in the comments!

Much of the new work I’m doing these days is being stored in git repositories. Now, I’m not the biggest fan of git, particularly its UI, but the advantages of GitHub and GitX are hard to ignore. Despite that, I still really missed being able to type hg out to see which patches I would be pushing, so, after a short chat with (and demo from) Ben, I came up with the following:

Somewhere in your path, add a file named git-outgoing which contains the following contents:

# !/bin/sh
# Uh, there shouldn’t be a space between the # and ! in the previous
# line, but the highlighter I’m using seems to require it…
git push --dry-run $1 2>&1 | awk '/^ / {print $1}' | xargs git log

(Make sure it’s executable by whomever needs to use it!)

Then, in your git config, add the following section:

[alias]
    out = outgoing

And finally, you should be able to type git out, and see something like:

commit 7d4c9b89a4663a07bed030669bae2d3c73ec78dc
Author: Blake Winton <bwinton@latte.ca>
Date:   Thu Dec 8 12:22:41 2011 -0500

    Blear 2

commit a4e8c6627bc26d7371fb2614a1c47aaf694957bd
Author: Blake Winton <bwinton@latte.ca>
Date:   Thu Dec 8 12:18:04 2011 -0500

    Bleah.

So, hopefully some of the rest of you will find this helpful, too, and if you know of a better way to do this, please let me know in the comments!

On a previous post in a different blog, some commenters were asking us if we were considering doing things that we have planned to do for a while now, and that led me to realize that I haven’t been communicating the future of Thunderbird’s UI nearly well enough. I mainly blame it on my trying to do too many other things, and thus failing to cover all the bases. So, having said all that, here is the list of things, in no particular order, that I would like to see worked on in the next few versions of Thunderbird. But first, I’ld like to say a little bit about why I want them.

I recently heard about someone who said “Thunderbird looks like iTunes”, and while that’s rather complimentary given the amount of time Apple puts into making things look good, it doesn’t really lead me to believe that people can pick our product out of a screenshot. And so one of the overall goals is to make Thunderbird iconic. You can always tell when a screenshot is of Apple mail, based on the layout and the lack of colour, and Firefox is similarly immediately recognizable because of the big circular back button and smaller rectangular forward button. Similarly, I’m hoping to have Thunderbird look different to other apps, while still fitting in on the platform, and maintaining a little consistency with Firefox. Of course, that’s not the only goal, nor even the main goal. My main idea for Thunderbird is to let you focus on the content that’s important to you, and not be distracted by things you don’t care about. Hopefully most of the changes I talk about here will help that, and as a side benefit also help to give us a more unique style.

• A simple thing that will make the product nicer to use is just to line things up. We’re all over the place, and it should be fairly simple to make this better. There are a couple of bugs that are related to this, and I suspect we could file a few more for various other parts.

• We want to put the tabs on top, because they let us put the compose and address book into tabs, while still having the appropriate toolbars. (As well, having everything be a tab makes the application more consistent, as described in the next point.)

• This leads into removing the standalone Compose and Address Book windows. You’ll still be able to open a window for those functions, but it will just be a regular window with a Compose or Address Book tab. (No bugs for this yet. Removals are sensitive things, and we want to get the replacement UI working well before we remove the existing UI.)

• We really want the Thunderbird button, so that we can hide the menus, and have less Glass on Windows, and make the most common actions easier to find and use.

• But, to add that button, we first need to see what the most common menu items people use are, therefore we need Test Pilot.

• We would like to add a HomeTab, to give people a personalized place to land when they start Thunderbird, or open a new window.

• We would like to merge the Gloda bar and Quick Filter bar, cause duh.

• Having two different settings locations is too confusing for me, let alone people who don’t care about the details of the product. We want to merge those into a single searchable place for all the settings, a la Mac System Prefs.

• This next change is more a small, personal thing, rather than part of a grand plan. It was originally suggested by Mike Beltzner, and while I’ve had some time to work on it, I haven’t had enough to push it through to completion. Basically, I’ld like to be able to order my email by date, while grouping it by subject. (This is different than threading, because I don’t care about which replies are to which messages. I just want a single group for the subject, with the messages ordered by date within that group, and the groups ordered by the date of the most recent message.) There’s no bug for this yet, but as mentioned, I started to write an extension, before hitting some annoying bugs that made it hard.

• Compactify the header. It’s really too big. Well, that’s a bit of a lie. What I really mean here is that we should move the buttons and their toolbar out of the header, to float just above it. This would allow people to easily turn them off (by removing the entire toolbar), and for those of us who like to keep them, it would make them more visually distinct. As an added bonus, in vertical mode, we could merge that toolbar with the other toolbars, to get something like the pictures of what Thunderbird could look like posted by Asa Dotzler.

• And finally, I think we should remove the Migration Assistant. It was very useful in the 2.0⇒3.0 transition, but it’s been less and less useful as time goes on, and as people have moved more and more onto Thunderbird 3, and 4, and 5… (No bug for this one either, again, because removals are sensitive things.)

See all the bugs in one big list.

Many thank-yous to Alex Faaborg, and areweprettyyet for the code to link the bugs, and the basis of the styling to make them stand out.

On a previous post in a different blog, some commenters were asking us if we were considering doing things that we have planned to do for a while now, and that led me to realize that I haven’t been communicating the future of Thunderbird’s UI nearly well enough. I mainly blame it on my trying to do too many other things, and thus failing to cover all the bases. So, having said all that, here is the list of things, in no particular order, that I would like to see worked on in the next few versions of Thunderbird. But first, I’ld like to say a little bit about why I want them.

I recently heard about someone who said “Thunderbird looks like iTunes”, and while that’s rather complimentary given the amount of time Apple puts into making things look good, it doesn’t really lead me to believe that people can pick our product out of a screenshot. And so one of the overall goals is to make Thunderbird iconic. You can always tell when a screenshot is of Apple mail, based on the layout and the lack of colour, and Firefox is similarly immediately recognizable because of the big circular back button and smaller rectangular forward button. Similarly, I’m hoping to have Thunderbird look different to other apps, while still fitting in on the platform, and maintaining a little consistency with Firefox. Of course, that’s not the only goal, nor even the main goal. My main idea for Thunderbird is to let you focus on the content that’s important to you, and not be distracted by things you don’t care about. Hopefully most of the changes I talk about here will help that, and as a side benefit also help to give us a more unique style.

• A simple thing that will make the product nicer to use is just to line things up. We’re all over the place, and it should be fairly simple to make this better. There are a couple of bugs that are related to this, and I suspect we could file a few more for various other parts.

• We want to put the tabs on top, because they let us put the compose and address book into tabs, while still having the appropriate toolbars. (As well, having everything be a tab makes the application more consistent, as described in the next point.)

• This leads into removing the standalone Compose and Address Book windows. You’ll still be able to open a window for those functions, but it will just be a regular window with a Compose or Address Book tab. (No bugs for this yet. Removals are sensitive things, and we want to get the replacement UI working well before we remove the existing UI.)

• We really want the Thunderbird button, so that we can hide the menus, and have less Glass on Windows, and make the most common actions easier to find and use.

• But, to add that button, we first need to see what the most common menu items people use are, therefore we need Test Pilot.

• We would like to add a HomeTab, to give people a personalized place to land when they start Thunderbird, or open a new window.

• We would like to merge the Gloda bar and Quick Filter bar, cause duh.

• Having two different settings locations is too confusing for me, let alone people who don’t care about the details of the product. We want to merge those into a single searchable place for all the settings, a la Mac System Prefs.

• This next change is more a small, personal thing, rather than part of a grand plan. It was originally suggested by Mike Beltzner, and while I’ve had some time to work on it, I haven’t had enough to push it through to completion. Basically, I’ld like to be able to order my email by date, while grouping it by subject. (This is different than threading, because I don’t care about which replies are to which messages. I just want a single group for the subject, with the messages ordered by date within that group, and the groups ordered by the date of the most recent message.) There’s no bug for this yet, but as mentioned, I started to write an extension, before hitting some annoying bugs that made it hard.

• Compactify the header. It’s really too big. Well, that’s a bit of a lie. What I really mean here is that we should move the buttons and their toolbar out of the header, to float just above it. This would allow people to easily turn them off (by removing the entire toolbar), and for those of us who like to keep them, it would make them more visually distinct. As an added bonus, in vertical mode, we could merge that toolbar with the other toolbars, to get something like the pictures of what Thunderbird could look like posted by Asa Dotzler.

• And finally, I think we should remove the Migration Assistant. It was very useful in the 2.0⇒3.0 transition, but it’s been less and less useful as time goes on, and as people have moved more and more onto Thunderbird 3, and 4, and 5… (No bug for this one either, again, because removals are sensitive things.)

See all the bugs in one big list.

Many thank-yous to Alex Faaborg, and areweprettyyet for the code to link the bugs, and the basis of the styling to make them stand out.

Add-ons are an important part of many Mozilla products, and many people have noticed that they’ve taken a hit as we’ve switched to the Rapid Release process. To help users have a little more control over how well their Firefox works, I would like to propose the following slight modification to the automatic Update process:

It all starts when Firefox (and Thunderbird) notice an update is available.

We immediately check the user’s add-ons to see if they are compatible, or if there are compatible versions we haven’t downloaded yet.

If all the add-ons are compatible (or will be made so at the next download), we show the NoAddons dialog:

It‘s the same as the current Firefox or Thunderbird update dialog, and as you would expect, the “Ask Later” and “Update Firefox” buttons do the same things that they do now.

On the other hand, if there are in-compatible add-ons, we show the Addons dialog:

As you can see, we let the user know which add-ons are incompatible, and give the user an extra button at the bottom to do something different.

The new “Update when my add-ons work” button (wording to be clarified later) will check the add-ons periodically, and automatically update Firefox when all the add-ons are compatible. If the add-ons aren’t compatible after a week (period of time to be configurable), the user will be shown this dialog again, with the (hopefully smaller) list of incompatible add-ons.

Showing the user which add-ons are incompatible will let them decide whether the add-ons are important enough to not upgrade, or whether they can live with the (hopefully short) period of reduced functionality.

As always, comments welcome, but keep them polite or they’ll be deleted.

Add-ons are an important part of many Mozilla products, and many people have noticed that they’ve taken a hit as we’ve switched to the Rapid Release process. To help users have a little more control over how well their Firefox works, I would like to propose the following slight modification to the automatic Update process:

It all starts when Firefox (and Thunderbird) notice an update is available.

We immediately check the user’s add-ons to see if they are compatible, or if there are compatible versions we haven’t downloaded yet.

If all the add-ons are compatible (or will be made so at the next download), we show the NoAddons dialog:

It‘s the same as the current Firefox or Thunderbird update dialog, and as you would expect, the “Ask Later” and “Update Firefox” buttons do the same things that they do now.

On the other hand, if there are in-compatible add-ons, we show the Addons dialog:

As you can see, we let the user know which add-ons are incompatible, and give the user an extra button at the bottom to do something different.

The new “Update when my add-ons work” button (wording to be clarified later) will check the add-ons periodically, and automatically update Firefox when all the add-ons are compatible. If the add-ons aren’t compatible after a week (period of time to be configurable), the user will be shown this dialog again, with the (hopefully smaller) list of incompatible add-ons.

Showing the user which add-ons are incompatible will let them decide whether the add-ons are important enough to not upgrade, or whether they can live with the (hopefully short) period of reduced functionality.

As always, comments welcome, but keep them polite or they’ll be deleted.

A friend of mine recently said:

EVERY behavior aspect of EVERY application should be user-settable if the user is prepared to drill down far enough. No exceptions. Even if the user will be shooting his own foot by messing with it.

I, obviously, disagree with him, and wanted to explain why in a few more characters than Twitter would allow.

While giving the user complete control over every aspect of an application seems like a good idea, there are two slightly-hidden downsides to it.

First, every choice you give the user doubles the amount of testing you have to do. (Okay, it doesn’t exactly double it, but it certainly adds a testing, maintenance, and support burden.) Is it a responsible use of your time to implement these options if less than 1% of your users will ever change them (and risk shooting their own feet), or would it be better for everyone to implement a feature that more people would use?

Second, Emacs notwithstanding, you’ll never get to a great text editor by customizing a mail reader. The whole Unix (and iOS, oddly) philosophy is to write each app to do one thing, and do it well. Not to do a whole bunch of optional things. And if you’re doing only one thing, presenting an option to the user to do it or not doesn’t make a lot of sense.

And finally, because I can’t count, if you offer people too much choice, it imposes a cognitive burden on them which can lead to their making no choices at all, or at least not making them any happier than when they had fewer choices.

To bring this back to the product I’m working on, we are going out of our way to make Thunderbird more usable and part of that is simplifying it by offering fewer, more meaningful choices.

A friend of mine recently said:

EVERY behavior aspect of EVERY application should be user-settable if the user is prepared to drill down far enough. No exceptions. Even if the user will be shooting his own foot by messing with it.

I, obviously, disagree with him, and wanted to explain why in a few more characters than Twitter would allow.

While giving the user complete control over every aspect of an application seems like a good idea, there are two slightly-hidden downsides to it.

First, every choice you give the user doubles the amount of testing you have to do. (Okay, it doesn’t exactly double it, but it certainly adds a testing, maintenance, and support burden.) Is it a responsible use of your time to implement these options if less than 1% of your users will ever change them (and risk shooting their own feet), or would it be better for everyone to implement a feature that more people would use?

Second, Emacs notwithstanding, you’ll never get to a great text editor by customizing a mail reader. The whole Unix (and iOS, oddly) philosophy is to write each app to do one thing, and do it well. Not to do a whole bunch of optional things. And if you’re doing only one thing, presenting an option to the user to do it or not doesn’t make a lot of sense.

And finally, because I can’t count, if you offer people too much choice, it imposes a cognitive burden on them which can lead to their making no choices at all, or at least not making them any happier than when they had fewer choices.

To bring this back to the product I’m working on, we are going out of our way to make Thunderbird more usable and part of that is simplifying it by offering fewer, more meaningful choices.

One of the big questions I had when I started writing patches was who I should ask to review them. Now that I’ve been in the community for a while, I’ve got a much better sense of who I should be talking to for the type of things I’m likely to write, but there are still times when I want to make a change in a part of the code that I haven’t touched before, and I’m not sure who to ask. In those cases, I usually fall back to a fairly simple (if non-obvious) set of steps to try and figure out who to pick.

1. Get the list of files I’ve changed.
2. Get the hg log for those files.
3. Check through the log for “r=”, and “sr=”.

Of course, that’s a fairly easy set of steps to automate, and so I present my first cut at the automated reviewer chooser!

Of course, there are a lot of things I’ld like to do with this, such as:

• Improving the documentation.
• Checking to see how well this script would have done on previous commits.
• Taking into account the length of the queues for the reviewers.
• Adding some sort of recent-ness calculations.

But I think that this tool is useful enough in its current state that releasing it and getting feedback on what to actually work on would be a win.

To use it, be in a mercurial source repo, and type getReviewer.py to get a list of suggested reviewers for the current differences, or getReviewer.py temp.diff or getReviewer.py https://bugzilla.mozilla.org/attachment.cgi\?id\=536017 to specify a different set of changes.

One of the big questions I had when I started writing patches was who I should ask to review them. Now that I’ve been in the community for a while, I’ve got a much better sense of who I should be talking to for the type of things I’m likely to write, but there are still times when I want to make a change in a part of the code that I haven’t touched before, and I’m not sure who to ask. In those cases, I usually fall back to a fairly simple (if non-obvious) set of steps to try and figure out who to pick.

1. Get the list of files I’ve changed.
2. Get the hg log for those files.
3. Check through the log for “r=”, and “sr=”.

Of course, that’s a fairly easy set of steps to automate, and so I present my first cut at the automated reviewer chooser!

Of course, there are a lot of things I’ld like to do with this, such as:

• Improving the documentation.
• Checking to see how well this script would have done on previous commits.
• Taking into account the length of the queues for the reviewers.
• Adding some sort of recent-ness calculations.

But I think that this tool is useful enough in its current state that releasing it and getting feedback on what to actually work on would be a win.

To use it, be in a mercurial source repo, and type getReviewer.py to get a list of suggested reviewers for the current differences, or getReviewer.py temp.diff or getReviewer.py https://bugzilla.mozilla.org/attachment.cgi\?id\=536017 to specify a different set of changes.

Since we released the GetAnAccount addon, we’ve had a lot of feedback. Many of the people who commented were looking for the option of getting an ad-supported account instead of paying for email access. We were always planning on integrating ad-supported services, as soon as we could, but of course, doing this required a redesign.

One important note before we get to the good stuff: I’ve used GMail soley as an example of a well-known ad-supported email provider here. We may or may not be partnering with them, and you should not take these screenshots as proof of our intentions one way or another.

As you can see from this first mockup, the initial view makes it much more obvious that you don’t need to create a new account just to use Thunderbird.

If you click in the bottom half, it expands up to make it more obvious that that’s what you want to do, and to allow us to display more information (although we don’t have any extra information to display there yet.

On the other hand, if you click on the top, we do have more information that you probably want to see before continuing on.

And this is something like what we hope to show you when the results have been returned. (Note: the Terms of Service, Existing Account, and Do It Later buttons are still there, but have been scrolled off the bottom of the dialog in this mockup.)

And finally, once you pick one of the providers, we expand that list to show you all of the results for that provider.

Feedback, as always, is welcome, either here or in the forum.

Since we released the GetAnAccount addon, we’ve had a lot of feedback. Many of the people who commented were looking for the option of getting an ad-supported account instead of paying for email access. We were always planning on integrating ad-supported services, as soon as we could, but of course, doing this required a redesign.

One important note before we get to the good stuff: I’ve used GMail soley as an example of a well-known ad-supported email provider here. We may or may not be partnering with them, and you should not take these screenshots as proof of our intentions one way or another.

As you can see from this first mockup, the initial view makes it much more obvious that you don’t need to create a new account just to use Thunderbird.

If you click in the bottom half, it expands up to make it more obvious that that’s what you want to do, and to allow us to display more information (although we don’t have any extra information to display there yet.

On the other hand, if you click on the top, we do have more information that you probably want to see before continuing on.

And this is something like what we hope to show you when the results have been returned. (Note: the Terms of Service, Existing Account, and Do It Later buttons are still there, but have been scrolled off the bottom of the dialog in this mockup.)

And finally, once you pick one of the providers, we expand that list to show you all of the results for that provider.

Feedback, as always, is welcome, either here or in the forum.

A co-worker of mine recently mentioned that he had a problem where he all-too-often accidentally quit his applications by hitting ⌘-q (command-q). Since he has been having problems with Thunderbird that I can’t fix, I thought I might do a little digging and see if I could come up with some way of helping him. And so here’s what I found:

In the System Preferences application, there’s a “Keyboard” section.

One of the things you can choose in that section is “Keyboard Shortcuts”.

Pick a relatively innocuous function, like turning Zoom on and off.

(Note: DO NOT choose Front Row for this!)

And assign that function to ⌘-q.

Now, whenever you hit ⌘-q, it will do whatever you selected, instead of quitting the application. Ta-da!

A co-worker of mine recently mentioned that he had a problem where he all-too-often accidentally quit his applications by hitting ⌘-q (command-q). Since he has been having problems with Thunderbird that I can’t fix, I thought I might do a little digging and see if I could come up with some way of helping him. And so here’s what I found:

In the System Preferences application, there’s a “Keyboard” section.

One of the things you can choose in that section is “Keyboard Shortcuts”.

Pick a relatively innocuous function, like turning Zoom on and off.

(Note: DO NOT choose Front Row for this!)

And assign that function to ⌘-q.

Now, whenever you hit ⌘-q, it will do whatever you selected, instead of quitting the application. Ta-da!

Over the past week, I’ve been working on fixing some of the reported bugs in the OpenSearch add-on for Thunderbird, and now I think I’ve fixed enough of them to release a new version.

You can find the full details on the Mozilla Labs blog, or you could just jump straight to the OpenSearch add-on page to install it. And please leave your feedback about the add-on on our Google group!

Over the past week, I’ve been working on fixing some of the reported bugs in the OpenSearch add-on for Thunderbird, and now I think I’ve fixed enough of them to release a new version.

You can find the full details on the Mozilla Labs blog, or you could just jump straight to the OpenSearch add-on page to install it. And please leave your feedback about the add-on on our Google group!

I was reading Making Software by Andy Oram and Greg Wilson, and got to the chapter about An Automated Fault Prediction System. It’s a pretty neat chapter, and it got me wondering which files in the Thunderbird code base had the most bugs. Now, I don’t have all the info I need, but I figured an easy first pass would be to go through the commit logs, and for each commit that started with “bug ”, add one to the files changed in that commit. Hmm, that sounded unintuitive. Let me just paste (and link) the code:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

from mercurial import ui, hg
import operator
import re

ext = re.compile("(\.c(pp)?|\.js|\.xml)$")

repo = hg.repository(ui.ui(), ".")
changes = [repo[i] for i in repo
                   if repo[i].description().lower().startswith("bug ")]

master = {}

for change in changes:
  files = [f for f in change.files() if ext.search(f)]
  for f in files:
    master[f] = master.get(f, 0) + 1

files = master.items()
files.sort()
counts = master.items()
counts.sort(key=operator.itemgetter(1))
counts.reverse()
print "\n".join([c[0] + ":" + str(c[1]) for c in counts[:10]])

And so, without further ado, here are the files that have been changed the most in bug fixes, and the number of times they've been changed:

• mail/base/content/mailWindowOverlay.js:109
• suite/browser/browser-prefs.js:73
• suite/browser/navigator.js:70
• mail/base/content/msgMail3PaneWindow.js:69
• mail/app/profile/all-thunderbird.js:67
• suite/common/src/nsSessionStore.js:66
• mail/components/compose/content/MsgComposeCommands.js:60
• mailnews/imap/src/nsImapMailFolder.cpp:56
• suite/browser/tabbrowser.xml:53
• mail/base/content/msgHdrViewOverlay.js:52

As a side note, for the mozilla repo it looks like this:

• js/src/jstracer.cpp:780
• browser/base/content/browser.js:654
• layout/base/nsCSSFrameConstructor.cpp:410
• layout/base/nsPresShell.cpp:400
• js/src/jsobj.cpp:399
• browser/base/content/tabbrowser.xml:397
• widget/src/windows/nsWindow.cpp:390
• toolkit/components/places/src/nsNavHistory.cpp:374
• js/src/jsinterp.cpp:345
• js/src/jsapi.cpp:343

I was reading Making Software by Andy Oram and Greg Wilson, and got to the chapter about An Automated Fault Prediction System. It’s a pretty neat chapter, and it got me wondering which files in the Thunderbird code base had the most bugs. Now, I don’t have all the info I need, but I figured an easy first pass would be to go through the commit logs, and for each commit that started with “bug ”, add one to the files changed in that commit. Hmm, that sounded unintuitive. Let me just paste (and link) the code:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

from mercurial import ui, hg
import operator
import re

ext = re.compile("(\.c(pp)?|\.js|\.xml)$")

repo = hg.repository(ui.ui(), ".")
changes = [repo[i] for i in repo
                   if repo[i].description().lower().startswith("bug ")]

master = {}

for change in changes:
  files = [f for f in change.files() if ext.search(f)]
  for f in files:
    master[f] = master.get(f, 0) + 1

files = master.items()
files.sort()
counts = master.items()
counts.sort(key=operator.itemgetter(1))
counts.reverse()
print "\n".join([c[0] + ":" + str(c[1]) for c in counts[:10]])

And so, without further ado, here are the files that have been changed the most in bug fixes, and the number of times they've been changed:

• mail/base/content/mailWindowOverlay.js:109
• suite/browser/browser-prefs.js:73
• suite/browser/navigator.js:70
• mail/base/content/msgMail3PaneWindow.js:69
• mail/app/profile/all-thunderbird.js:67
• suite/common/src/nsSessionStore.js:66
• mail/components/compose/content/MsgComposeCommands.js:60
• mailnews/imap/src/nsImapMailFolder.cpp:56
• suite/browser/tabbrowser.xml:53
• mail/base/content/msgHdrViewOverlay.js:52

As a side note, for the mozilla repo it looks like this:

• js/src/jstracer.cpp:780
• browser/base/content/browser.js:654
• layout/base/nsCSSFrameConstructor.cpp:410
• layout/base/nsPresShell.cpp:400
• js/src/jsobj.cpp:399
• browser/base/content/tabbrowser.xml:397
• widget/src/windows/nsWindow.cpp:390
• toolkit/components/places/src/nsNavHistory.cpp:374
• js/src/jsinterp.cpp:345
• js/src/jsapi.cpp:343

Dear Santa,

Everyone else is doing it, so here’s my list, too.

• A Blu-Ray of a fireplace, perhaps with a secondary audio track of christmas music.
• Dollhouse Season 2 on Blu-Ray.
• Books are always nice. I’m in the mood for one of Ian Banks' Culture series, but I’m not sure which ones I haven’t read.
• Whichever Usagi Yojimbo collections I’m missing.
• Another two (or three!) sets of BuckyBalls. (I would get Zen Magnets, but I’ve already got BuckyBalls, and I don’t think I want to mix them.
• a digital photo frame, for the office.
• A tiny usb monitor. (There are also touch-screen versions for more money, but I’m a little leery about them.)
• Perhaps an Arduino to play around with.

Well, that’s all I can think of off the top of my head.

Thanks, Blake.