From: Marek Szuba <marecki@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] [RFC] Moving more architectures to ~arch only
Date: Thu, 4 Nov 2021 18:08:12 +0000 [thread overview]
Message-ID: <6d75681f-acf2-99a0-1b93-8874a264df0e@gentoo.org> (raw)
In-Reply-To: <53861fbb-0ba5-45d8-eccf-dc9244dc6b32@gentoo.org>
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
next prev parent reply other threads:[~2021-11-04 18:08 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-14 13:40 [gentoo-dev] [RFC] Moving more architectures to ~arch only Marek Szuba
2021-10-14 16:08 ` Roy Bamford
2021-10-14 17:10 ` Michał Górny
2021-10-15 6:54 ` Joonas Niilola
2021-10-15 7:20 ` Agostino Sarubbo
2021-10-15 11:59 ` Mikhail Koliada
2021-10-15 21:40 ` Rolf Eike Beer
2021-10-16 6:17 ` Michał Górny
2021-11-04 18:56 ` Rolf Eike Beer
2021-10-16 21:14 ` William Hubbs
2021-10-18 0:25 ` Thomas Deutschmann
2021-10-18 1:08 ` John Helmert III
2021-10-18 15:09 ` Thomas Deutschmann
2021-10-18 17:07 ` Michał Górny
2021-10-19 15:36 ` Thomas Deutschmann
2021-10-18 17:32 ` Rolf Eike Beer
2021-11-04 18:08 ` Marek Szuba [this message]
2021-10-18 0:50 ` Sam James
2021-10-18 0:54 ` Sam James
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6d75681f-acf2-99a0-1b93-8874a264df0e@gentoo.org \
--to=marecki@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox