1 |
On Sun, 14 Aug 2016 23:35:58 +0200 |
2 |
Kristian Fiskerstrand <k_f@g.o> wrote: |
3 |
|
4 |
> * The b.g.o workflow, bugs should not be considered fixed until the |
5 |
> fix has reached the stable tree. Today the InVCS keyword exists for |
6 |
> this purpose, but it is used to varying degree amongst developers. |
7 |
> Will a workflow change to introduce a new status, e.g RESOLVED |
8 |
> NeedsStable (name for illustration purpose only) incentivize |
9 |
> developers to not close bugs before it is fixed? |
10 |
|
11 |
Here you're essentially marking "RESOLVED" to be "Fixed In Stable" |
12 |
|
13 |
There's a problem I have here with this: If we have a keyword that in effect is |
14 |
intended to say "This bug is fixed in stable", the problem there is there's no |
15 |
way, at least, not in the context of the bug, or the bug metadata, to draw |
16 |
anything meaningful from that. |
17 |
|
18 |
Because "Stable" is in my estimation typically not a single state. |
19 |
|
20 |
We like to presume it is, but the reality is a significant number of packages |
21 |
have "mixed" stability states. |
22 |
|
23 |
And the stability process itself is also arch specific, and so they don't |
24 |
all stabilize together, some, languishing by months. |
25 |
|
26 |
So: "NeedsStable"(sic) means what exactly? |
27 |
|
28 |
And if "Resolved" is "Stable is done", what does that mean? |
29 |
|
30 |
Does "NeedsStable" mean "All arches that are deemed stable need to be stabilized |
31 |
for this bug"? |
32 |
|
33 |
What about packages that don't have any stable version, and are not anywhere |
34 |
on a prioritization for stabilization? |
35 |
|
36 |
What about packages that are stable only on a few arches? |
37 |
|
38 |
The lack of bugs having an "affected platforms" field as such makes reverse |
39 |
searching for such things when you're touching a bug needlessly complicated. |
40 |
|
41 |
You can at best approximate it by searching for cc@ properties, but that only |
42 |
matters for packages that are *currently* pending keywording. |
43 |
|
44 |
And I doubt people are going to be CCing arches for every bug that "NeedsStable" |
45 |
|
46 |
You can I guess create some form of referential integrity, where you have to |
47 |
assign every bug that gets fixed to a stable request in order to ensure its completion. |
48 |
|
49 |
But that's getting into problems of causality, needing to assign a stability |
50 |
request to a bug before stabilization is needed just to determine "which arches" |
51 |
|
52 |
This sort of stuff makes me feel bugzilla is entirely the wrong platform for |
53 |
handling stabilizations and keywords :/ |