On Wed, Jan 15, 2014 at 4:54 AM, Michał Górny <mgo...@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
