Concerned about the number of open regressions in the past year
dolphinling
Firefox2!) there have been 642 bugs filed with the "regression" keyword in Core
or Firefox that are still open[1]. That seems like a lot to me.
I've seen a bunch on the newsgroups and planet and other places about what makes
a bug worth blocking on, but has blocking on sheer numbers been discussed at all?
Also, would going through and looking for ones that have been resolved make a
good topic for a bugday? Past statistics about regressions say probably about
150-250 of them are either invalid or duplicate or have already been fixed by
something and are worksforme. That's still 400-500 valid ones, though.
--
dolphinling
<http://dolphinling.net/>
L. David Baron
> I've seen a bunch on the newsgroups and planet and other places
> about what makes a bug worth blocking on, but has blocking on
> sheer numbers been discussed at all?
One of the things I often bring up when somebody mentions that
blocking+ should mean that we can't ship a release with a certain
bug in it is that if a bug is bad enough such that 10 bugs that bad
mean we couldn't ship, then we probably need to track it. Probably
even if it's bad enough that 100 bugs that bad mean we couldn't ship
-- if we think we have close to 100 such bugs.
The optimal way to do bug triage, in theory, is to assign each bug a
number N that says how many bugs of that bugs severity would block
us from shipping. Then we'd ship when the sum over bugs of 1/N went
below 1.
The reality is that assigning numbers that precisely might be more
work than fixing the bugs. So really what we do for blocking+ is
say that it's equivalent to N being less than some value -- where N
decreases as we have fewer bugs total and get closer to release (the
reason bugs get minused late in the cycle).
Is it worth considering a better approximation for
$$\sum_{b} \frac{1}{N_b} < 1$$? I'm not sure.
-David
--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/
Robert O'Callahan
> I've seen a bunch on the newsgroups and planet and other places about what makes
> a bug worth blocking on, but has blocking on sheer numbers been discussed at all?
In layout, most bugs marked 'regression' are being marked blockers.
Sometimes not, e.g. if it's not clear the new behaviour is actually
wrong.
Rob
Robert O'Callahan
'regression' but not blocking1.9+? Broken down by component?
Rob
Boris Zbarsky
> In the past year since firefox 2 was released (happy birthday tomorrow,
> Firefox2!) there have been 642 bugs filed with the "regression" keyword
> in Core or Firefox that are still open[1]. That seems like a lot to me.
It _is_ a lot, yes. I have a few questions:
1) How many of those regressions are neither blocking1.9+ nor blocking1.9?
2) How many (if it's easy to get this data) are regressions from Gecko 1.8
as opposed to regressions from earlier Gecko releases?
> I've seen a bunch on the newsgroups and planet and other places about
> what makes a bug worth blocking on, but has blocking on sheer numbers
> been discussed at all?
I think David has summarized the situation here pretty well. In general, any
regression from 1.8 should be at least considered for 1.9 blocking, in my opinion.
> Also, would going through and looking for ones that have been resolved
> make a good topic for a bugday?
Absolutely. I'd be willing to bet that a number of these bugs are also in the
wrong place component-wise.
I should also note that the few bugs I glanced at had regression ranges.... but
were not in any way linked to the bug that caused the regression or mentioned in
it. Not an effective way of getting things fixed. :(
-Boris
Boris Zbarsky
> 1) How many of those regressions are neither blocking1.9+ nor blocking1.9?
That should have been:
How many of those regressions are neither "blocking1.9+" nor "blocking1.9?" ?
-Boris
dolphinling
I'm not sure I did my queries right, as I can't get negations of the flags to
work (so I'm just subtracting) but it looks like:
blocking1.9? blocking1.9+ notblocking Total
blockingff3? blockingff3+
Core 65 126 303 494
Firefox 5 50 89 144
Total 70 176 392 638
PS: I wish bugzilla would let you have a report's columns/rows be the state of a
flag...
--
dolphinling
<http://dolphinling.net/>
dolphinling
> blocking1.9? blocking1.9+ notblocking Total
> blockingff3? blockingff3+
> Core 65 126 303 494
> Firefox 5 50 89 144
> Total 70 176 392 638
Also, there are 54 bugs in core (with "regression", the date, etc.) that are
blocking1.9-. 31 of those have [wanted-1.9] in the status whiteboard, and there
is 1 [wanted-1.9] with blocking1.9 unset, 1 [wanted-1.9] with blocking1.9?, and
two with blocking1.9+.
There's also a wanted1.9 flag, but I couldn't find anything that used it. I
think there's an equivalent status whiteboard/flag for firefox, but I don't know
what it is.
--
dolphinling
<http://dolphinling.net/>