Re: [gentoo-dev] [RFC] Moving more architectures to ~arch only

[Marek Szuba]

Sorry about a long delay responding, I ended up being offline until the 
end of last week and I've had quite a lot of catching up.

Anyway, let me begin by addressing a sentiment expressed independently 
in several responses and which could be summarised as "just come and 
help". A laudable idea in theory - except as a project run entirely by 
unpaid volunteers, we can neither hire more people nor demand that 
developers work on more things than they already do. It might sound 
harsh but if working in particle physics (which like most public-sector 
research suffers from chronic shortage of manpower comparing to the 
amount of things to do, and which is nowadays based primarily on 
large-scale collaborations whose leadership has only minimal authority 
over individual participants) has taught me anything, it's that it is 
better to do a good job at two things than a mediocre one at ten.

Moving on to specific comments:


On 18/10/2021 01:50, Sam James wrote:

 > - Most failures found via arch testing _aren't_ arch-specific, but 
they serve as a useful quality check. That is,
 > usually, we're not held back by some odd e.g. SIGBUS that nobody 
knows how to fix.

Possibly true (I've got no evidence to make a definite statement either 
way) - but there is a point in testing, or in pretty much any technical 
activity, when the amount of work required to polish something further 
begins to strongly outweigh the benefits.

Moreover, the above doesn't really sound to me like a case in defence of 
stabilisation on exotic arches; quite the opposite in fact.

 > - Encourage developers to run test suites on their packages. This is 
a modern part of Gentoo development
 > and isn't optional if a package has a functioning test suite which 
isn't hell to get running - i.e. you should really
 > _try_.

People who do not do this yet should be taken behind the chemicals shed 
and sho... I mean, be very much ashamed of themselves. Not sure what 
that has got to do with arch testing though, given what kind of hardware 
most of us do Gentoo development on.

 > - We drop any large suites of packages at least to ~arch where 
they're problematic.

In addition to the dependency-creep problem already mentioned by Michał, 
I am not convinced that arbitrarily declaring some package or other not 
worthy of stable status on arch X would make the user experience on this 
arch better than downgrading the whole arch to ~X. Furthermore, I am 
pretty sure arch testers would then have to keep track of which packages 
must not be stabilised where - meaning more work.

On 18/10/2021 01:25, Thomas Deutschmann wrote:

> Could you please elaborate what you are expecting from this change?
>
> I.e. will this solve any problem (please name it)? Will it allow us to
> move forward where we are blocked at the moment (please name it)?

One part of this has already been mentioned by the others, i.e. all too 
often low activity on these arches ends up delaying overall progress of 
things such security issues for ALL Gentoo users.

Another is that IMHO there are way too few people active in these arch 
teams to keep up with the work load - even including sam's activity 
pretty much all over the place, which at this rate I fear will result in 
him burning out soon, things are far from great.

On 15/10/2021 22:40, Rolf Eike Beer wrote:

 > My machines should actually do some useful stuff, like running my 
Nagios and a
 > bunch of nightly builds (CMake, libarchive, things like that). For 
that, I'd
 > like to have the actual system to work. Given the amount of breakage 
I find
 > when doing stabilizations I suspect this is not going to happen.

Maybe, maybe not... If my experience with RISC-V keywording is anything 
to go by, a lot of breakage comes from unexpected interactions due to 
throwing everything but a kitchen sink on a single system - which having 
to deal with stabilisation makes more likely, especially on an arch 
which does not see many new keywording requests (on riscv, which is 
still quite active in this respect, I simply run all keywording tests 
with --oneshot and regularly distclean the system).


On 14/10/2021 18:10, Michał Górny wrote:

 > While we're discussing it, maybe we should start by defining a clear
 > criteria for platform support tiers?  Like: what are the requirements
 > for a platform to maintain stable keywords?  Then the decisions could
 > look less arbitrary, and people would have a clear way of knowing what
 > they need to do if they wish the platform to continue having stable
 > keywords.

Not a bad idea but I wonder how much effort we might want to throw at 
this, especially given we're not Red Hat or SUSE.

-- 
MS