Gentoo Archives: gentoo-dev

From: Sam James <sam@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] [RFC] Moving more architectures to ~arch only
Date: Mon, 18 Oct 2021 00:51:01
Message-Id: 440A4515-A8CB-4E9F-B03F-57018D4A09FF@gentoo.org
In Reply to: [gentoo-dev] [RFC] Moving more architectures to ~arch only by Marek Szuba
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

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies