bug 640452<\/a> (which I’ll henceforth call “mlk-fx5+”), with which I’ve been tracking leaks in the lead-up to Firefox 5 and later versions.\u00a0 I carried over unresolved bugs from mlk-fx4-old.\u00a0 mlk-fx5+ is starting to fill up feel stale.\u00a0 Basically, I can see it suffering the same problems as the ‘mlk’ keyword before too long.<\/p>\nSo I’m thinking about changing how these are tracked.\u00a0 The basic idea is to use keep using the ‘mlk’ keyword for all leak reports, and then have one leak-tracking bug for each version of Firefox, so it’s clear which version each report applies to.<\/p>\n
Steps needed to start this<\/h3>\n
Add the ‘mlk’ keyword to all mlk-fx4-old and mlk-fx5+ bugs that lack it.<\/p>\n
Open new tracking bugs: mlk-fx4-beta, mlk-fx4, mlk-fx5, mlk-fx6.\u00a0 (The Firefox 4 beta period was long enough, and there were enough leak reports filed against beta versions, that separating mlk-fx4-beta and mlk-fx4 seems worthwhile.)\u00a0 Make each mlk-fxN depend on mlk-fx(N-1).<\/p>\n
For all the existing bugs tracked by mlk-fx4-old and mlk-fx5+, add them to the appropriate new tracking bug.\u00a0 With one exception: for hopelessly vague ones, just mark them as duplicates of mlk-fxN, with an explanatory message (“we’re not ignoring leaks, look at all these ones we’re tracking!\u00a0 but your report doesn’t tell us anything we don’t already know, sorry”).<\/p>\n
Close mlk-fx5+.<\/p>\n
Steps needed to maintain this in the future<\/h3>\n
When Firefox version N’s cycle starts, open mlk-fxN, and mark it as depending on mlk-fx(N-1).<\/p>\n
For all new leak reports, mark it as blocking mlk-fxN, for appropriate N.\u00a0 Also add the ‘mlk’ keyword.<\/p>\n
If someone confirms in a comment that a problem reported in version N is still present in version N+1, mark that bug as also blocking mlk-fx(N+1).<\/p>\n
Properties of this system<\/h3>\n
You can still search for all leak reports, based on the ‘mlk’ keyword.<\/p>\n
You can immediately tell roughly how stale a report is likely to be, based on which mlk-fxN tracking bug it blocks.\u00a0 This is more reliable than the bug number or file date;\u00a0 for example, we are still getting reports against Firefox 4 even though Firefox 5 (which has fixed a number of leaks) is in beta and Firefox 6 just went to Aurora.\u00a0 This immediately gives a starting priority for all leak reports:\u00a0 more recent ones have higher priority because they’re more likely to still be unfixed.<\/p>\n
Hopelessly vague reports are resolved immediately by duplicating, so they don’t clog things up.<\/p>\n
Tracking bugs shouldn’t get too big and unwieldy, because each Firefox version has a limited lifespan.<\/p>\n
Reports against version N still block mlk-fx(N+1), but via one level of indirection.\u00a0 Reports against version N+2 still block mlk-fx(N+2), but via two levels of indirection, etc.\u00a0 So the full chain of dependencies is maintained.<\/p>\n
We could periodically go through older bugs (eg. 3 releases ago) and ask people to re-confirm, and close out ones that get no response.\u00a0 But we wouldn’t have to do that.<\/p>\n
Am I crazy?<\/h3>\n
Is this bureaucratic overkill?\u00a0 I don’t think so.\u00a0 It’ll take some work, but I’m happy to do that.\u00a0 It’ll only take an hour or two to set up, and then it won’t be much harder to maintain than what I’m currently doing with the mlk-fx5+ bug.\u00a0 (I also have plans for writing instructions to help users file better leak reports.)\u00a0 And it’ll allow us to proceed much more usefully with the lists of leak reports that we have.<\/p>\n
But I’m interested to hear if you disagree, or have any ideas for improving it.\u00a0 Thanks!<\/p>\n","protected":false},"excerpt":{"rendered":"
We get lots of leak reports from users.\u00a0 There is a spectrum of quality. Some are hopelessly vague and will never lead to anything useful. (“After browsing for several hours, Firefox is using 100s of MBs of memory.\u00a0 This is unacceptable;\u00a0 please fix.”)\u00a0 Bug 643177 is an example. Some are very precise.\u00a0 This makes them […]<\/p>\n","protected":false},"author":139,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[142,30,4544,4546],"tags":[],"_links":{"self":[{"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/posts\/822"}],"collection":[{"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/users\/139"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/comments?post=822"}],"version-history":[{"count":0,"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/posts\/822\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/media?parent=822"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/categories?post=822"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/tags?post=822"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}