1 |
El sáb, 15-02-2014 a las 14:30 +0100, Jeroen Roovers escribió: |
2 |
[...] |
3 |
> The only reasonable course of action is to start dropping stable |
4 |
> keywords for $ARCH, after a reasonable timeout. It gets tricky if this |
5 |
> involves removing many keywords on dependencies, but if that's what you |
6 |
> have to do to keep cat/pkg (and eclasses and profiles) in shape, then |
7 |
> by all means _help_ _out_ $ARCH by doing it for them. If that means |
8 |
> removing stable/unstable support for an entire DM or scripting |
9 |
> framework, then so be it. |
10 |
|
11 |
I agree with this... but, if I don't misremember, there are others that |
12 |
don't want to do this :/ From the big Gnome 3.8 bug, I have noticed that |
13 |
we can only handle easily amd64 and x86. Probably arm in the future (at |
14 |
least Steev if putting lots of effort to trying to test it at runtime on |
15 |
his ARM devices... but it looks to be pretty hard). With ia64 I was able |
16 |
to find an arch tester that is helping really a lot, but for the rest of |
17 |
arches... (ppc, ppc64, alpha, sparc), I have been unable to even find |
18 |
arch testers that could help. |
19 |
|
20 |
Personally, I think that, before starting to discuss what to do with |
21 |
"uncommon" arches we would need to decide how to test things on this |
22 |
arches: |
23 |
- Compile test only -> if we agree on this, probably the current |
24 |
situation can be kept a bit more |
25 |
- Runtime test required -> this will for sure need to start to dropping |
26 |
lots of packages to "testing only". |
27 |
|
28 |
I am not strongly in favor of any of them but I think we need to agree |
29 |
on what to do. Current situation is like a ugly mix: bugs are piled for |
30 |
a long long time until some people goes ahead and does the compile test |
31 |
only. And I think they do what probably is the current only way to do |
32 |
until we decide what kind of testing we want for this more "exotic" |
33 |
arches. |