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
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)