1 |
15.01.2014 03:49, Tom Wijsman пишет: |
2 |
> On Tue, 14 Jan 2014 15:37:19 -0600 |
3 |
> William Hubbs <williamh@g.o> wrote: |
4 |
> |
5 |
>> Thoughts? |
6 |
> |
7 |
> In this situation, I see three opposite ends of choices: |
8 |
> |
9 |
> 1. "We do nothing"; which means that as a side effect either less |
10 |
> often a version would be picked for stabilization or stabilizations |
11 |
> will just take longer due to a longer queue. The question here is |
12 |
> whether the queue is actually growing; to get a quick idea, we could |
13 |
> compare the amount of bugs we have now compared to those of last time. |
14 |
> |
15 |
> Advantage: We keep the same policy and quality of stabilization. |
16 |
> |
17 |
> Disadvantage: Stable runs further behind. Waiting time. Frustration. |
18 |
> |
19 |
> Resources: We need to find more people for the arch teams. |
20 |
> |
21 |
> 2. "We crowd source it"; which means we tackle the 'low manpower' |
22 |
> problem itself, we invite at a larger scale feedback for packages in |
23 |
> one or another way. This ranges from a simple reminder when merging a |
24 |
> non-stable package to report back whether it is working, to a more |
25 |
> large scale new website effort where this can be done much more |
26 |
> organized; but that's a whole discussion on its own. |
27 |
> |
28 |
> Advantage: Power to the community. Need for arch teams decreases. |
29 |
> |
30 |
> Disadvantage: Stabilization quality could drop. Enough feedback? |
31 |
> |
32 |
> Resources: We need to patch up and/or write enough to pull |
33 |
> attention from the user that there aid is needed. |
34 |
> |
35 |
> 3. "We make stable mean less"; which means that we accept the 'low |
36 |
> manpower' problem, this would as a consequence thus mean that because |
37 |
> we cannot put in enough effort to deem everything stable anymore. The |
38 |
> word 'stable' would thus mean less, instead of 'thoroughly tested by |
39 |
> a separate person' it becomes 'tested by the same maintainer'. |
40 |
> |
41 |
> Advantage: Gentoo becomes slightly more bleeding edge. |
42 |
> |
43 |
> Disadvantage: Problematic for important packages were stabilization |
44 |
> is really needed; 'stability' of some user application |
45 |
> has a much smaller meaning than on a library shared |
46 |
> between multiple applications of the user. |
47 |
> |
48 |
> Resources: Less resources used, though it might yield more bugs. |
49 |
> |
50 |
> Of course this is not meant to limit other choices, there might be |
51 |
> others and I hope people bring them forward; as a closing word it feels |
52 |
> hard to decide here, especially since it can have quite an effect on |
53 |
> the distribution. As put above neither option seems convincing, neither |
54 |
> option seems like it is without risk; does anyone have a different view? |
55 |
> |
56 |
> Unless we only do a small version of those options, like changing a |
57 |
> minor detail instead of pushing it through at once; which could be a |
58 |
> more safe step forward. Which smaller options do we have here? |
59 |
> |
60 |
> If at all, maybe experiment something on one arch to start with? |
61 |
> |
62 |
|
63 |
As i said earlier for similar proposals - the one option that i see here |
64 |
to make all things going better - to recruit more people in arch |
65 |
teams/arch testers. Other options lead us to nowhere, when stable will |
66 |
be eliminated or transformed into fake. |
67 |
|
68 |
-- |
69 |
Best regards, Sergey Popov |
70 |
Gentoo developer |
71 |
Gentoo Desktop Effects project lead |
72 |
Gentoo Qt project lead |
73 |
Gentoo Proxy maintainers project lead |