[arch-dev-public] Starting x86_64_v3 port

[Maxime Gauduin]

On Sat, 2022-01-29 at 20:17 +0100, Sven-Hendrik Haase via arch-dev-
public wrote:
> 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

We already have 2 working automated build tools, that I know of,
Evangelos' and mine [0]. I'm sure we can figure something out fairly
quickly, unless we'd rather go with some Gitlab CI now that we have
one. It would probably make more sense to go that route, but I've
already fitted several Gitlab instances with a Buildbot CI, I find it
more flexible and it also works wonders.

[0] https://github.com/alucryd/archbuild

Cheers,
-- 
Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 516 bytes
Desc: This is a digitally signed message part
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20220130/7fe69bc1/attachment.sig>