| 1 |
On Wed, Jan 15, 2014 at 4:54 AM, Michał Górny <mgorny@g.o> wrote: |
| 2 |
> |
| 3 |
> 2) has to add package.accept_keywords entry for the package. Which |
| 4 |
> means turning a pure stable system into an unsupported mixed-keyword |
| 5 |
> system. |
| 6 |
|
| 7 |
As opposed to an unsupported pure stable system or an unsupported pure |
| 8 |
unstable system? I doubt anybody runs a pure stable system, and if |
| 9 |
they do I doubt their experience is much different from those who run |
| 10 |
mixed keywords. |
| 11 |
|
| 12 |
Of course, having random system packages drop stable keywords from |
| 13 |
time to time isn't going to help anything in that department. |
| 14 |
|
| 15 |
Obviously maintainers should keep stable system packages around as |
| 16 |
long as they can. However, there needs to be some way to deal with |
| 17 |
cases where their stabilization gets held up on a major arch. If we |
| 18 |
don't have the manpower to stabilize newer versions, what makes |
| 19 |
anybody think that maintainers have the manpower to "support" ancient |
| 20 |
versions? |
| 21 |
|
| 22 |
The have our cake and eat it too solution is to obtain more manpower. |
| 23 |
That should be done without question, but for whatever reason it never |
| 24 |
actually happens, so we need to think about what the alternative is. |
| 25 |
If talking about it scares more people into volunteering so that it |
| 26 |
isn't necessary all the better... |
| 27 |
|
| 28 |
Given constrained manpower the options basically are some variation on: |
| 29 |
1. Status quo - for some packages stable gets REALLY old, and likely |
| 30 |
has problems that maintainers ignore. You can't force somebody to |
| 31 |
maintain something any more than you can force somebody to test |
| 32 |
something. |
| 33 |
|
| 34 |
2. We become more liberal with stabilizing newer versions. Lots of |
| 35 |
variations on this, but the bottom line is that packages get |
| 36 |
stabilized that would otherwise not be. |
| 37 |
|
| 38 |
3. We drop stable keywords on packages. Lots of variations on this |
| 39 |
as well, but the result is mixed-arch systems or dropping stable for |
| 40 |
the whole arch. |
| 41 |
|
| 42 |
I don't think #1 is really the answer - it just results in |
| 43 |
less-visible problems and a stable that is probably works worse than |
| 44 |
either #2 or #3 would yield. |
| 45 |
|
| 46 |
#2 has the advantage that it gives us more control over what gets |
| 47 |
installed on stable systems and you don't end up with mixed keywords. |
| 48 |
The downside to #2 is that the user doesn't have as much visibility |
| 49 |
into which packages are "really" stable. Maybe an in-between quality |
| 50 |
tier would help (if you're going to run a mixed keyword system, at |
| 51 |
least use this version). |
| 52 |
|
| 53 |
#3 has the advantage that it makes the problem directly visible to the |
| 54 |
user. However, the solution ends up being entirely user-discretion. |
| 55 |
Some users end up on ~arch for life, others do it version-by-version |
| 56 |
in which case they end up on various versions. Personally I run |
| 57 |
stable and when I need to run unstable on a package I tend to use |
| 58 |
<cat/foo-major+1 syntax so that I'm tracking unstable until the next |
| 59 |
major version and then I get a chance to revisit the decision - |
| 60 |
usually stable catches up by then. |
| 61 |
|
| 62 |
The only "nice" solution is more manpower. I'd like a pony to go with |
| 63 |
that as well... |
| 64 |
|
| 65 |
Rich |
Archives