| 1 |
Rich Freeman wrote: |
| 2 |
> > Why not make stable completely optional for arch teams? |
| 3 |
> |
| 4 |
> Stable already is completely optional for the arch teams, and that is |
| 5 |
> why we have concerns over stable requests taking forever on minor |
| 6 |
> archs in the first place. If the package wasn't marked as stable in |
| 7 |
> the first place the maintainer could just drop old versions anytime |
| 8 |
> they saw fit, but in the cases that cause problems the arch team |
| 9 |
> exercises their option to stabilize something, and then they also |
| 10 |
> exercise their option to not stabilize something newer. |
| 11 |
|
| 12 |
Aha, I understand. Thanks! |
| 13 |
|
| 14 |
I don't think that's "completely optional" though, it sounds like a |
| 15 |
one-way function. If have ever stabilized a package once then must |
| 16 |
ensure a stable package forever. |
| 17 |
|
| 18 |
I think arbitrarily removing stable versions should also be an option, |
| 19 |
and I think package managers would be able to deal with that without |
| 20 |
much extra effort? |
| 21 |
|
| 22 |
Stabilization is the distribution stretching time of upstream |
| 23 |
development. I think it's more healthy for upstream (and thus |
| 24 |
also for the distribution) to have the distribution be very thin, |
| 25 |
so that users rather interact directly with upstream. |
| 26 |
|
| 27 |
But that's of course not everyone's ideal, and that's fine. :) |
| 28 |
|
| 29 |
|
| 30 |
//Peter |
Archives