Comments on: Why Firefox 3.0.11 gained a point on Acid3 http://whereswalden.com/2009/06/15/why-firefox-3-0-11-gained-a-point-on-acid3/ Mozilla, politics, economics, law, backpacking, cycling, and other random desiderata Fri, 27 Apr 2012 03:03:18 +0000 hourly 1 http://wordpress.org/?v=3.3.2 By: Where's Walden? » Whole-text DOM functionality and Acid3 redux http://whereswalden.com/2009/06/15/why-firefox-3-0-11-gained-a-point-on-acid3/comment-page-1/#comment-140612 Where's Walden? » Whole-text DOM functionality and Acid3 redux Thu, 18 Mar 2010 18:19:54 +0000 http://whereswalden.com/?p=763#comment-140612 [...] A bug in UTF-16 processing [...] [...] A bug in UTF-16 processing [...]

]]> By: Dan http://whereswalden.com/2009/06/15/why-firefox-3-0-11-gained-a-point-on-acid3/comment-page-1/#comment-134845 Dan Tue, 16 Jun 2009 19:33:18 +0000 http://whereswalden.com/?p=763#comment-134845 Indeed, perhaps enforcing what I suggested for security bugs only would be manageable. Another way to make it more manageable would be to have a maximum time period that you need to go back to (when deciding whether the bug is a regression or not). I don't think it's entirely unmanageable, many people already follow this "binary search" procedure when filing bugs. Indeed, perhaps enforcing what I suggested for security bugs only would be manageable. Another way to make it more manageable would be to have a maximum time period that you need to go back to (when deciding whether the bug is a regression or not). I don’t think it’s entirely unmanageable, many people already follow this “binary search” procedure when filing bugs.

]]> By: anonymous http://whereswalden.com/2009/06/15/why-firefox-3-0-11-gained-a-point-on-acid3/comment-page-1/#comment-134827 anonymous Mon, 15 Jun 2009 19:31:46 +0000 http://whereswalden.com/?p=763#comment-134827 Very interesting post. I'd say the key failure was that nobody realized 439206 was a regression. Though, if you don't know that a bug is a regression, it is non-trivial to find out whether it is in fact a regression. For every bug you would need to at least check all the major releases. Theoretically, you would have to check every changeset to ensure that something is not a regression. [Exactly what I alluded to in the previous comment, regarding the costs of doing so.] Very interesting post. I’d say the key failure was that nobody realized 439206 was a regression. Though, if you don’t know that a bug is a regression, it is non-trivial to find out whether it is in fact a regression. For every bug you would need to at least check all the major releases. Theoretically, you would have to check every changeset to ensure that something is not a regression.

[Exactly what I alluded to in the previous comment, regarding the costs of doing so.]

]]> By: Dan http://whereswalden.com/2009/06/15/why-firefox-3-0-11-gained-a-point-on-acid3/comment-page-1/#comment-134826 Dan Mon, 15 Jun 2009 19:25:19 +0000 http://whereswalden.com/?p=763#comment-134826 If bug 439206 had been identified as a regression when it was filed, and that the culprit had been identified by finding the changeset that caused it and backing out the patch, this issue would have been avoided, right? It would then be clear that if that patch had to be backported, so did the first patch. Perhaps another lesson is if a bug is found on trunk, the bug that regressed it must be identified, or it should be shown not to be a regression. [Also a reasonable conclusion. Again, I defer to people with more QA experience to say if following those steps is an overall win or not, because that <em>is</em> an awful lot of time tracking down regressions whose origin may not matter. Perhaps it should merely be a requirement for security bugs — that might reduce the cost enough to make it more obviously a win.] If bug 439206 had been identified as a regression when it was filed, and that the culprit had been identified by finding the changeset that caused it and backing out the patch, this issue would have been avoided, right? It would then be clear that if that patch had to be backported, so did the first patch. Perhaps another lesson is if a bug is found on trunk, the bug that regressed it must be identified, or it should be shown not to be a regression.

[Also a reasonable conclusion. Again, I defer to people with more QA experience to say if following those steps is an overall win or not, because that is an awful lot of time tracking down regressions whose origin may not matter. Perhaps it should merely be a requirement for security bugs — that might reduce the cost enough to make it more obviously a win.]

]]>