1 |
Jose Luis Rivero wrote: |
2 |
> I would prefer to analyze the causes of the slacker arch (manpower, |
3 |
> hardware, etc) and if we are not able to solve the problem by any way |
4 |
> (asking for new devs, buying hardware, etc) go for mark it as |
5 |
> experimental and drop all stable keywords. |
6 |
|
7 |
How is that better? Instead of dropping one stable package you'd end up |
8 |
dropping all of them. A user could accept ~arch and get the same |
9 |
behavior without any need to mark every other package in the tree |
10 |
unstable. An arch could put a note to that effect in their installation |
11 |
handbook. The user could then choose between a very narrow core of |
12 |
stable packages or a wider universe of experimental ones. |
13 |
|
14 |
I guess the question is whether package maintainers should be forced to |
15 |
maintain packages that are outdated by a significant period of time. |
16 |
Suppose something breaks a package that is 3 versions behind stable on |
17 |
all archs but one (where it is the current stable). Should the package |
18 |
maintainer be required to fix it, rather than just delete it? I suspect |
19 |
that the maintainer would be more likely to just leave it broken, which |
20 |
doesn't exactly leave things better-off for the end users. |
21 |
|
22 |
I'm sure the maintainers of qt/baselayout/coreutils/etc will exercise |
23 |
discretion on removing stable versions of these packages. However, for |
24 |
some obscure utility that next-to-nobody uses, does it really hurt to |
25 |
move from stable back to unstable if the arch maintainers can't keep up? |
26 |
|
27 |
I guess it comes down to the driving issues. How big a problem are |
28 |
stale packages (with the recent movement of a few platforms to |
29 |
experimental, is this an already-solved problem?)? How big of a problem |
30 |
do arch teams see keeping up with 30-days as (or maybe 60/90)? What are |
31 |
the practical (rather than theoretical) ramifications? |