1 |
Richard Freeman wrote: |
2 |
> Jose Luis Rivero wrote: |
3 |
>> I would prefer to analyze the causes of the slacker arch (manpower, |
4 |
>> hardware, etc) and if we are not able to solve the problem by any way |
5 |
>> (asking for new devs, buying hardware, etc) go for mark it as |
6 |
>> experimental and drop all stable keywords. |
7 |
> |
8 |
> How is that better? Instead of dropping one stable package you'd end up |
9 |
> dropping all of them. A user could accept ~arch and get the same |
10 |
> behavior without any need to mark every other package in the tree |
11 |
> unstable. |
12 |
|
13 |
Accept ~arch for the random package which has lost the stable keyword a |
14 |
random day? And next week .. which is going to be the next? The key is |
15 |
the concept 'stable' and what you hope of it. |
16 |
|
17 |
A long/middle-term solution for arches with very few resources instead |
18 |
of generating problems to users seems a much better approach to me. |
19 |
|
20 |
> An arch could put a note to that effect in their installation |
21 |
> handbook. The user could then choose between a very narrow core of |
22 |
> stable packages or a wider universe of experimental ones. |
23 |
|
24 |
Mixing software branches is very easy in the Gentoo world but it has |
25 |
some problems. Are you going to install in your stable (production, |
26 |
critial, important,...) system a combination of packages not tested |
27 |
before? Because the arch teams or the maintainers are not going to test |
28 |
every posible combination of core stable + universe of experimental |
29 |
packages. This is why branches exists. |
30 |
|
31 |
> I guess the question is whether package maintainers should be forced to |
32 |
> maintain packages that are outdated by a significant period of time. |
33 |
> Suppose something breaks a package that is 3 versions behind stable on |
34 |
> all archs but one (where it is the current stable). Should the package |
35 |
> maintainer be required to fix it, rather than just delete it? |
36 |
|
37 |
Maintainer has done all he can do, this means: that is broken, this |
38 |
version fix the problem, go for it. Maintainer's job finishes here, now |
39 |
it's the problem of your favorite arch team. |
40 |
|
41 |
> I suspect |
42 |
> that the maintainer would be more likely to just leave it broken, which |
43 |
> doesn't exactly leave things better-off for the end users. |
44 |
|
45 |
It's a different approach (maybe with the same bad results) but |
46 |
different anyway. Leave the bug there, point the user to the bug and |
47 |
maybe you can gain a new dev or an arch tester. |
48 |
|
49 |
While the proposal made here is to throw random keyword problems to |
50 |
users by policy (which in the case of amd64 some months ago would have |
51 |
created a complete disaster). |
52 |
|
53 |
> I'm sure the maintainers of qt/baselayout/coreutils/etc will exercise |
54 |
> discretion on removing stable versions of these packages. However, for |
55 |
> some obscure utility that next-to-nobody uses, does it really hurt to |
56 |
> move from stable back to unstable if the arch maintainers can't keep up? |
57 |
|
58 |
Special cases and special plans are allowed, what we are discussing here |
59 |
is a general and accepted policy. |
60 |
|
61 |
> I guess it comes down to the driving issues. How big a problem are |
62 |
> stale packages (with the recent movement of a few platforms to |
63 |
> experimental, is this an already-solved problem?)? How big of a problem |
64 |
> do arch teams see keeping up with 30-days as (or maybe 60/90)? What are |
65 |
> the practical (rather than theoretical) ramifications? |
66 |
|
67 |
An interesting discussion. Ask our council to listen all parts: |
68 |
maintainers, current arch teams, the experience of mips, etc. and try to |
69 |
make a good choice. |
70 |
|
71 |
Thanks Richard. |
72 |
|
73 |
-- |
74 |
Jose Luis Rivero <yoswink@g.o> |
75 |
Gentoo/Alpha Gentoo/Do |