Comment 94 for bug 225379

Revision history for this message
In , Bzbarsky (bzbarsky) wrote :

It's taken more like 21 months, as far as I can tell (the bug was first reported against 1.9a3, in March 2007).

Basically, the timeline breaks down as follows:

1) Bug reported in Firefox:General (wrong place for it, and apparently not
   triaged much, sadly).
2) It takes 11 months for someone other than the reporter to comment on the bug.
3) It takes 3 months for someone who knows how the bug system works to see the
   bug, confirm it and request blocking.
4) Almost immediately the bug is moved to Core:General (another wrong place,
   and even worse-triaged than Firefox:General).
5) The next day it's decided that the bug isn't a blocker for the release.
   It's moved into the Networking component, which is basically unowned (at the
   time, of the three peers, one (the owner) was working on Google Chrome and
   not reading bugmail, one had a non-Mozilla-related job and wasn't reading
   bugmail much, and one had a PhD defence coming up in 2 weeks time and hadn't
   been really dealing with bugmail for 6 months).
6) Nothing relevant happens for a month and a half until Adam Spain takes the
   time to go through and figure out when the bug first appeared (something
   anyone with time could have done, for what it's worth). At this point,
   people figure out which change cased the problem and finally move the bug
   to the correct component (imagelib). Sadly, at this point imagelib is not
   so well-owned. The previous owner has moved on to other things, and the new
   one hasn't gotten up to speed yet.
7) Two days later there is a guess as to how to fix the bug. Unfortunately, the
   person doing the guessing (one of the network peers mentioned above) is in
   the middle of moving from Chicago to Boston at the time and has a 7-month
   backlog of bugmail due to the the PhD thing I mentioned.
8) A month later the bug is moved out of imagelib and to docshell of all
   places, claiming that it's a bug in the bfcache, not in imagelib (this in
   spite of a regression range blaming an imagelib change).
9) Another month and a half later, there's more information about what might
   need to happen to fix this, but the commenter is still working through that
   seven-month backlog and working on bugs that are considered higher priority
   (see the "not blocking" determination earlier).
10) Another two weeks later a fix is finally attached to the bug.
11) 3 days later a patch that works for Firefox 3 is attached.
12) A week and a half later, the trunk patch gets reviewed and is checked in.
    Approval is requested for the branch fix.
13) A month and a bit later, it's approved. The next day it's fixed on the
    branch.
14) It's another month and a half until the next branch release at this point.

I have no idea why approval took so long, but the real lag time was in getting the bug to the attention of people who had both the knowledge and the time to do something with it, combined with the lack of active code ownership in the most-relevant modules (imagelib and network).