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

[Rich Freeman <rich0@gentoo.org>]

On Wed, Jan 15, 2014 at 4:54 AM, Michał Górny <mgorny@gentoo.org> wrote:
>
> 2) has to add package.accept_keywords entry for the package. Which
> means turning a pure stable system into an unsupported mixed-keyword
> system.

As opposed to an unsupported pure stable system or an unsupported pure
unstable system?  I doubt anybody runs a pure stable system, and if
they do I doubt their experience is much different from those who run
mixed keywords.

Of course, having random system packages drop stable keywords from
time to time isn't going to help anything in that department.

Obviously maintainers should keep stable system packages around as
long as they can.  However, there needs to be some way to deal with
cases where their stabilization gets held up on a major arch.  If we
don't have the manpower to stabilize newer versions, what makes
anybody think that maintainers have the manpower to "support" ancient
versions?

The have our cake and eat it too solution is to obtain more manpower.
That should be done without question, but for whatever reason it never
actually happens, so we need to think about what the alternative is.
If talking about it scares more people into volunteering so that it
isn't necessary all the better...

Given constrained manpower the options basically are some variation on:
1.  Status quo - for some packages stable gets REALLY old, and likely
has problems that maintainers ignore.  You can't force somebody to
maintain something any more than you can force somebody to test
something.

2.  We become more liberal with stabilizing newer versions.  Lots of
variations on this, but the bottom line is that packages get
stabilized that would otherwise not be.

3.  We drop stable keywords on packages.  Lots of variations on this
as well, but the result is mixed-arch systems or dropping stable for
the whole arch.

I don't think #1 is really the answer - it just results in
less-visible problems and a stable that is probably works worse than
either #2 or #3 would yield.

#2 has the advantage that it gives us more control over what gets
installed on stable systems and you don't end up with mixed keywords.
The downside to #2 is that the user doesn't have as much visibility
into which packages are "really" stable.  Maybe an in-between quality
tier would help (if you're going to run a mixed keyword system, at
least use this version).

#3 has the advantage that it makes the problem directly visible to the
user.  However, the solution ends up being entirely user-discretion.
Some users end up on ~arch for life, others do it version-by-version
in which case they end up on various versions.  Personally I run
stable and when I need to run unstable on a package I tend to use
<cat/foo-major+1 syntax so that I'm tracking unstable until the next
major version and then I get a chance to revisit the decision -
usually stable catches up by then.

The only "nice" solution is more manpower.  I'd like a pony to go with
that as well...

Rich