| 1 |
On Mon, Aug 15, 2016 at 8:24 AM, Michael Orlitzky <mjo@g.o> wrote: |
| 2 |
> |
| 3 |
> If we have to wait for a fix to hit stable before I can close a bug, who |
| 4 |
> should I assign it to? I don't want 200 bugs, that I can do literally |
| 5 |
> nothing about, assigned to me for years while I wait for them to get |
| 6 |
> stabilized. It's also going to kill my motivation knowing that, no |
| 7 |
> matter how hard I work, my bug count is never going to go down. |
| 8 |
> |
| 9 |
|
| 10 |
I think that a lot of this discussion centers around changing the bug |
| 11 |
states while assuming that developers will continue to use the same |
| 12 |
views they already use. |
| 13 |
|
| 14 |
Today developers tend to use views that exclude resolved bugs. |
| 15 |
Perhaps tomorrow they'll tend to use views that exclude bugs that are |
| 16 |
resolved or waiting for stabilization. Perhaps these views will |
| 17 |
become the defaults. |
| 18 |
|
| 19 |
Or maybe we leave the states alone and add a new field to track |
| 20 |
whether the bug is stable on any/all/each arch (not sure which is |
| 21 |
best). |
| 22 |
|
| 23 |
One concern which I think is legitimate is the extra bookkeeping. If |
| 24 |
we're going to track a bunch of bugs through a long stabilization |
| 25 |
cycle (think desktop environments), we don't want devs to have to |
| 26 |
spend hours figuring out which bugs can be closed out. And we don't |
| 27 |
want them skipping that step either. It might make sense to tag bugs |
| 28 |
with a version and then have the states automatically update when the |
| 29 |
bugs are released. |
| 30 |
|
| 31 |
-- |
| 32 |
Rich |
Archives