1 |
On 06/17/2016 02:18 PM, Rich Freeman wrote: |
2 |
> On Fri, Jun 17, 2016 at 7:58 AM, Kristian Fiskerstrand <k_f@g.o> wrote: |
3 |
>> On 06/17/2016 01:50 PM, Rich Freeman wrote: |
4 |
>>> It might be better to just close the original bug, and then open a new |
5 |
>>> STABLEREQ bug on the tracker whenever we're interested in tracking |
6 |
>>> stabilization. That also serves as a reminder to the maintainer that |
7 |
>>> somebody actually wants it stabilized. |
8 |
>> |
9 |
>> This adds another layer of complexity and requires multiple |
10 |
>> depend/blocks specifications for a single user. I also question whether |
11 |
>> these stabilization requests would be created if the original devs |
12 |
>> aren't willing to call for stabilization themselves or leave the bug |
13 |
>> open so you have the history of the issue available for the |
14 |
>> stabilization, filtering it out based on keyword is easy to do in saved |
15 |
>> search. |
16 |
>> |
17 |
> |
18 |
> Can you clarify what you mean by that? |
19 |
> |
20 |
> If I have a tracker with 47 resolved blockers, how do I know which of |
21 |
> those made it to stable? |
22 |
> |
23 |
|
24 |
The once that are RESOLVED FIXED, before they are in stable they should |
25 |
be open with InVCS keyword |
26 |
|
27 |
> If I'm a maintainer and I resolve a bug, how do I know if I should |
28 |
> mark it resolved or not before it is stable? |
29 |
|
30 |
If package is in stable to begin with, I would certainly prefer it not |
31 |
to be marked fixed before it is in stable in all cases to avoid that |
32 |
ambiguity. keywords are useful for search and filtering |
33 |
|
34 |
> |
35 |
> If the bug is resolved but still needs to be tracked to stable, how |
36 |
> does anybody realize that bug is still out there and needs to be |
37 |
> marked as stable? |
38 |
|
39 |
It shouldn't be closed before it is in stable to begin with, issue solved |
40 |
|
41 |
> |
42 |
> The problem is that tracking bugs to stable is not the normal process, |
43 |
> so if we want to do it we need to come up with some way to make it |
44 |
> obvious that it needs to be done. Or have some way to automate this |
45 |
> using data from the repository/etc. |
46 |
|
47 |
Tracking bugs are a separate matter, in particular for feature |
48 |
development etc, I use this e.g for [gnupg] |
49 |
> |
50 |
> Apologies if this email is a bit confusing. There are a couple of |
51 |
> proposals out there and I'm trying to address all of them - not all of |
52 |
> those questions will make sense for every proposal. |
53 |
> |
54 |
|
55 |
References: |
56 |
[gnupg] https://bugs.gentoo.org/show_bug.cgi?id=552936 |
57 |
|
58 |
|
59 |
-- |
60 |
Kristian Fiskerstrand |
61 |
OpenPGP certificate reachable at hkp://pool.sks-keyservers.net |
62 |
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 |