| 1 |
On Fri, Jun 17, 2016 at 7:58 AM, Kristian Fiskerstrand <k_f@g.o> wrote: |
| 2 |
> On 06/17/2016 01:50 PM, Rich Freeman wrote: |
| 3 |
>> It might be better to just close the original bug, and then open a new |
| 4 |
>> STABLEREQ bug on the tracker whenever we're interested in tracking |
| 5 |
>> stabilization. That also serves as a reminder to the maintainer that |
| 6 |
>> somebody actually wants it stabilized. |
| 7 |
> |
| 8 |
> This adds another layer of complexity and requires multiple |
| 9 |
> depend/blocks specifications for a single user. I also question whether |
| 10 |
> these stabilization requests would be created if the original devs |
| 11 |
> aren't willing to call for stabilization themselves or leave the bug |
| 12 |
> open so you have the history of the issue available for the |
| 13 |
> stabilization, filtering it out based on keyword is easy to do in saved |
| 14 |
> search. |
| 15 |
> |
| 16 |
|
| 17 |
Can you clarify what you mean by that? |
| 18 |
|
| 19 |
If I have a tracker with 47 resolved blockers, how do I know which of |
| 20 |
those made it to stable? |
| 21 |
|
| 22 |
If I'm a maintainer and I resolve a bug, how do I know if I should |
| 23 |
mark it resolved or not before it is stable? |
| 24 |
|
| 25 |
If the bug is resolved but still needs to be tracked to stable, how |
| 26 |
does anybody realize that bug is still out there and needs to be |
| 27 |
marked as stable? |
| 28 |
|
| 29 |
The problem is that tracking bugs to stable is not the normal process, |
| 30 |
so if we want to do it we need to come up with some way to make it |
| 31 |
obvious that it needs to be done. Or have some way to automate this |
| 32 |
using data from the repository/etc. |
| 33 |
|
| 34 |
Apologies if this email is a bit confusing. There are a couple of |
| 35 |
proposals out there and I'm trying to address all of them - not all of |
| 36 |
those questions will make sense for every proposal. |
| 37 |
|
| 38 |
-- |
| 39 |
Rich |
Archives