Gentoo Archives: gentoo-dev

From: Sergey Popov <pinkbyte@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] rfc: revisiting our stabilization policy
Date: Wed, 15 Jan 2014 11:40:34
Message-Id: 52D673A4.2080508@gentoo.org
In Reply to: Re: [gentoo-dev] rfc: revisiting our stabilization policy by Tom Wijsman
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

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies

Subject Author
Re: [gentoo-dev] rfc: revisiting our stabilization policy Tom Wijsman <TomWij@g.o>