1 |
On Mon, 15 Aug 2016 15:03:08 +0200 |
2 |
Kristian Fiskerstrand <k_f@g.o> wrote: |
3 |
|
4 |
> Could you please elaborate a bit? In particular from perspective of (i) |
5 |
> integration into current workflow, (ii) complexity in application |
6 |
> maintenance/hosting (iii) cost/benefit considerations |
7 |
|
8 |
Biggest irritation is that "bugs track concepts" but "arches track arches" |
9 |
so "One bug many arches" -> Anarchy. |
10 |
|
11 |
A competing tool I'd imagine would possibly automatically designate packages |
12 |
that are stable /candidates/ and keywording /candidates/ without any manual |
13 |
interaction. |
14 |
|
15 |
ie: It would essentially double down on the "Batch stabilization/keywording" |
16 |
concept and represent that concept portage wide, but only in an informal sense. |
17 |
|
18 |
Then you could basically filter it by views on a per-arch basis to see what |
19 |
needs doing on a given arch, and mark "candidates" as "needed to be done" |
20 |
and tree based recursive integrity checking would be part of the workflow. |
21 |
|
22 |
So you'd see "X is stable candidate for x86" |
23 |
You'd click "x86" and it would produce a list of the subgraph that also needs |
24 |
stabilizing to satisfy, and you'd give it a once over, click "Ok" and that package |
25 |
and its dependencies are now "marked for stabilization on x86". |
26 |
|
27 |
Then AT teams could come along and simply use a different view that shows only |
28 |
stabilization requests for their arch, and do them in bulk, or piecemeal, |
29 |
at their own discretion. |
30 |
|
31 |
unkeyworded -> keywording candidate -> keywording request -> keyworded |
32 |
|
33 |
keyworded -> stable candidate -> stable request -> stable |
34 |
|
35 |
But these are just ideas ;) |