22 |
unacceptable in some way. How to judge this depends on the severity and scope |
unacceptable in some way. How to judge this depends on the severity and scope |
23 |
of the bug, and ability of the programmers on hand to fix the bug. Overall |
of the bug, and ability of the programmers on hand to fix the bug. Overall |
24 |
stability is desirable (see stability.text). |
stability is desirable (see stability.text). |
25 |
|
|
26 |
|
|
27 |
|
When to call a bug Release Critical |
28 |
|
----------------------------------- |
29 |
|
|
30 |
|
mvo sez: |
31 |
|
|
32 |
|
> I can explain the criteria for each bug specifically, but I wouldn't feel |
33 |
|
> comfortable to do this generally. One fundamental criterium, however, is that |
34 |
|
> the fix does not affect people who are not also affected by the bug. When the |
35 |
|
> fix is also short and well localized, and the bug is relatively severe (i.e., |
36 |
|
> making Guile fail to compile on a not-really-obscure platform), I'm tempted to |
37 |
|
> make it release critical. |
38 |
|
|
39 |
|
ttn sez: |
40 |
|
|
41 |
|
> when the bug is internal, to some extent guile developers can emulate |
42 |
|
> the user response by running "make check" or whatever to ensure that the |
43 |
|
> fix does not upset the user experience, and fulfill the closure. |
44 |
|
> |
45 |
|
> when the bug has to do w/ user-visible interface (as is the case here), |
46 |
|
> this emulation is insufficient because the likely outcome is that this |
47 |
|
> or some other user will complain, placing developers in a defensive |
48 |
|
> position, which is not fun for anyone. there is also the clear message |
49 |
|
> that spreads into the community that developers are not responsive to |
50 |
|
> user concerns. this is plain uncool. |
51 |
|
> |
52 |
|
> all this suggests that one of the criteria for application of |
53 |
|
> release-critical tag is "does this bug involve user-visible interface?". |