[arch-dev-public] Starting x86_64_v3 port

[Sven-Hendrik Haase]

On Sat, 29 Jan 2022 at 15:17, Pierre Schmitz via arch-dev-public <
arch-dev-public at lists.archlinux.org> wrote:

> On Sat, Jan 29, 2022 at 2:49 PM Allan McRae via arch-dev-public
> <arch-dev-public at lists.archlinux.org> wrote:
> > Assuming we need people to help the x86_64_v3 port, I would post a news
> > item and have people apply.  We have advertised developer positions in
> > the past and received dozens of applications, and readily filled the
> > available positions with quality applicants.  They would be brought on
> > as Package Maintainers (once approved on the staff list) with access to
> > [extra] and [community], and have packaging privileges including being
> > added to the keyring.
> >
> > While advertising for x86_64_v3 specific packagers, we should make a
> > list of other packaging areas needing help and recruit for those too.
>
> While I would have preferred to gradually have raised the CPU
> requirements of our main repo (e.g. v2 right now and v3 in a few
> years), maintaining two x86_64 variants for a transition period might
> work. Nonetheless we should in work on how to get Arch back to be
> bleeding edge regardless of this. One aspect might be to reduce the
> overall amount of packages and get rid of unmaintained software
> (either by us or upstream).
>
> As the vast majority of hardware is v3 already we should consider
> x86_64 (<v3) to be deprecated. I'd even recommend to agree on a date
> when support for such CPUs will be dropped. Personally I would only
> use and test on v3 once it is available. While not all of you might
> agree right now, this is how it will end up eventually, like it did
> with i686. Long story short: we might be looking for people
> maintaining the x86_64 repos and not the v3 ones.
>
> Greetings,
>
> Pierre
>
> --
> Pierre Schmitz, https://pierre-schmitz.com


This wouldn't really be too much of an issue if we had proper automation.
With automation, this exact problem solves itself to a degree. Surely there
will still be specific breakages now and then but the bulk of the burden
will go away. We'd even be able to support other targets with ease.

However, I realize this will require a lot of upfront infra work before
we're there and I'm not sure we should block this proposal on that work.

If we don't eventually get good automation (and packages in git), this
kinda problem will keep reoccurring. Sadly I don't really have time to work
on this right now though I'd love to.

Sven