1 |
> On 14 Oct 2021, at 14:40, Marek Szuba <marecki@g.o> wrote: |
2 |
> |
3 |
> Dear everyone, |
4 |
> |
5 |
> Following some private discussions, I feel quite strongly now that it would both considerably improve certain processes and make our use of limited manpower more efficient were we to further reduce the number of stable arches in Gentoo Linux. Specifically, I propose to drop |
6 |
> - hppa, |
7 |
> - ppc, |
8 |
> - sparc, |
9 |
> - x86 |
10 |
> to ~arch-only status. |
11 |
|
12 |
I'm not sure we should go down this route. Dakon's email covers a lot of the reasons, but I'll try to add to it my own rationale too: |
13 |
|
14 |
- Most failures found via arch testing _aren't_ arch-specific, but they serve as a useful quality check. That is, |
15 |
usually, we're not held back by some odd e.g. SIGBUS that nobody knows how to fix. |
16 |
|
17 |
- We're not really helping users by making such a change. Any problems which prevent stabilisation still exist. We're |
18 |
just reducing the quality of the Gentoo experience for users on these arches. |
19 |
|
20 |
My suggested actions: |
21 |
|
22 |
- As referenced below, make more developers aware they're welcome to have access to our various exotic |
23 |
hardware! |
24 |
|
25 |
- Encourage developers to run test suites on their packages. This is a modern part of Gentoo development |
26 |
and isn't optional if a package has a functioning test suite which isn't hell to get running - i.e. you should really |
27 |
_try_. |
28 |
|
29 |
- Further, encouraging tatt/pkg-testing-tools like Dakon suggested before pushing new ebuilds. A wiki page |
30 |
I've started might prove helpful too: https://wiki.gentoo.org/wiki/User:Sam/Useful_scripts#Testing. |
31 |
|
32 |
- We drop any large suites of packages at least to ~arch where they're problematic. A good place |
33 |
to start would probably be scientific stuff which isn't a test dependency (or likely to become one) |
34 |
in future of e.g. the Python stack. There's quite a few niche sci applications stable on e.g. x86 |
35 |
which probably don't have a need to be. |
36 |
|
37 |
The gist being, I think we can focus our efforts (and try educate + encourage others to help) |
38 |
without completely shutting the door here. |
39 |
|
40 |
I'm quite happy helping with these arches right now (although hppa is problematic |
41 |
due to the speed of our current hardware, we are wondering if we can get some |
42 |
other kit) as long as we all continue to chip in. But more help is very welcome and desired. |
43 |
|
44 |
What would probably help more than anything else right now is dropping stable keywords |
45 |
for irrelevant packages (not wasting time on some stablereqs where nobody is probably |
46 |
using that $application on $arch) and having a tool to easily report bugs so I don't waste time |
47 |
copying/pasting logs. |
48 |
|
49 |
(slyfox actually mentioned his desire for such a tool in his farewell post: https://trofi.github.io/posts/226-farewell-gentoo-dev.html). |
50 |
|
51 |
Now, addressing the rest of the email: |
52 |
|
53 |
> Note that this does NOT mean we intend to drop support for those arches altogether. |
54 |
> |
55 |
> There are IMHO several good reasons for this: |
56 |
> - most of the arches from this list are quite dated and either aren't really developed upstream any more or got superseded by newer ones (for the record, it's been 18 years since the first amd64 CPUs came out) |
57 |
|
58 |
But users of this hardware can only really get by on Gentoo without super-super-frequent updates. Not all versions added to ~arch to get stabilised and also once stabled are less likely |
59 |
to have e.g. build failures so less wasted time. |
60 |
|
61 |
> - we have got very few people actually supporting these arches, and in case of hppa there is also the hardware bottleneck. Subsequently, stabilisation requests often take a long time to resolve |
62 |
|
63 |
I think a better way of tackling this is to make developers aware they can even access a lot of this hardware! I don't think |
64 |
many developers realise they're welcome to have access to our various arch testing machines -- they're not just |
65 |
for a select few. We want more help! |
66 |
|
67 |
> [snip] |
68 |
|
69 |
best, |
70 |
sam |