Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Sergey Popov <pinkbyte@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 3387 bytes --]

15.01.2014 03:49, Tom Wijsman пишет:
> On Tue, 14 Jan 2014 15:37:19 -0600
> William Hubbs <williamh@gentoo.org> wrote:
> 
>> Thoughts?
> 
> In this situation, I see three opposite ends of choices:
> 
>   1. "We do nothing"; which means that as a side effect either less
>   often a version would be picked for stabilization or stabilizations
>   will just take longer due to a longer queue. The question here is
>   whether the queue is actually growing; to get a quick idea, we could
>   compare the amount of bugs we have now compared to those of last time.
> 
>   Advantage:    We keep the same policy and quality of stabilization.
> 
>   Disadvantage: Stable runs further behind. Waiting time. Frustration.
> 
>   Resources:    We need to find more people for the arch teams.
> 
>   2. "We crowd source it"; which means we tackle the 'low manpower'
>   problem itself, we invite at a larger scale feedback for packages in
>   one or another way. This ranges from a simple reminder when merging a
>   non-stable package to report back whether it is working, to a more
>   large scale new website effort where this can be done much more
>   organized; but that's a whole discussion on its own.
> 
>   Advantage:    Power to the community. Need for arch teams decreases.
> 
>   Disadvantage: Stabilization quality could drop. Enough feedback?
> 
>   Resources:    We need to patch up and/or write enough to pull
>                 attention from the user that there aid is needed.
> 
>   3. "We make stable mean less"; which means that we accept the 'low
>   manpower' problem, this would as a consequence thus mean that because
>   we cannot put in enough effort to deem everything stable anymore. The
>   word 'stable' would thus mean less, instead of 'thoroughly tested by
>   a separate person' it becomes 'tested by the same maintainer'.
> 
>   Advantage:    Gentoo becomes slightly more bleeding edge.
> 
>   Disadvantage: Problematic for important packages were stabilization 
>                 is really needed; 'stability' of some user application
>                 has a much smaller meaning than on a library shared
>                 between multiple applications of the user.
> 
>   Resources:    Less resources used, though it might yield more bugs.
> 
> Of course this is not meant to limit other choices, there might be
> others and I hope people bring them forward; as a closing word it feels
> hard to decide here, especially since it can have quite an effect on
> the distribution. As put above neither option seems convincing, neither
> option seems like it is without risk; does anyone have a different view?
> 
> Unless we only do a small version of those options, like changing a
> minor detail instead of pushing it through at once; which could be a
> more safe step forward. Which smaller options do we have here?
> 
> If at all, maybe experiment something on one arch to start with?
> 

As i said earlier for similar proposals - the one option that i see here
to make all things going better - to recruit more people in arch
teams/arch testers. Other options lead us to nowhere, when stable will
be eliminated or transformed into fake.

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Qt project lead
Gentoo Proxy maintainers project lead


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]