| 1 |
On Thu, Jun 16, 2016 at 3:02 PM, Michał Górny <mgorny@g.o> wrote: |
| 2 |
> Hello, everyone. |
| 3 |
> |
| 4 |
> Here's the third bugs.g.o redesign RFC. |
| 5 |
> |
| 6 |
> This time it's about closed bugs. Right now we have two states for |
| 7 |
> them: RESOLVED and VERIFIED. |
| 8 |
> |
| 9 |
> RESOLVED is the usual state that the developers use when they close |
| 10 |
> a bug. It's also the only state that could be directly transferred from |
| 11 |
> other states. |
| 12 |
> |
| 13 |
> VERIFIED is used scarcely, and not really consistently. It can only be |
| 14 |
> used on RESOLVED bugs, and sometimes users use it to confirm that |
| 15 |
> the bug is resolved. |
| 16 |
> |
| 17 |
> To be honest, I don't really see the need for VERIFIED state. Since |
| 18 |
> it's used scarcely, it can't be really relied upon. Some users use it |
| 19 |
> completely incorrectly (e.g. when the bug should be reopened instead). |
| 20 |
|
| 21 |
Agreed. However I don't see a strong reason to remove it, unless its |
| 22 |
removal simplifies the introduction of STABILIZED. If it's useful to |
| 23 |
some people, let them use it. |
| 24 |
|
| 25 |
> |
| 26 |
> What I'd like to introduce instead is a new STABILIZED state. It would |
| 27 |
> -- like VERIFIED now -- be only available for bugs already RESOLVED, |
| 28 |
> and it could be used to signify that the fix has made it into stable. |
| 29 |
> |
| 30 |
> While this wouldn't be really obligatory, it would be meaningful for |
| 31 |
> trackers that need to ensure that fixes in packages have made it to |
| 32 |
> stable -- like the functions.sh use tracker. |
| 33 |
|
| 34 |
Makes sense, although, as you said yourself, if it's not used |
| 35 |
consistently it cannot be relied upon. Besides, we already have a |
| 36 |
mechanism for expressing this, we make the stable request bug block |
| 37 |
the tracker. |
| 38 |
|
| 39 |
Thanks, |
| 40 |
Davide |
Archives