[arch-dev-public] Starting x86_64_v3 port

[Morten Linderud]

On Sat, Jan 29, 2022 at 10:53:41PM +1000, Allan McRae via arch-dev-public wrote:
> On 29/1/22 22:11, Morten Linderud via arch-dev-public wrote:
> > On Sat, Jan 29, 2022 at 11:45:57AM +1000, Allan McRae via arch-dev-public wrote:
> > > On 29/1/22 11:28, Morten Linderud via arch-dev-public wrote:
> > > > On Sat, Jan 29, 2022 at 11:22:32AM +1000, Allan McRae via arch-dev-public wrote:
> > > > > On 29/1/22 11:13, Morten Linderud via arch-dev-public wrote:
> > > > > > On Sat, Jan 29, 2022 at 10:12:30AM +1000, Allan McRae via arch-dev-public wrote:
> > > > > > > Is there any particular objection to requiring packagers upload both
> > > > > > > architectures?
> > > > > > 
> > > > > > I'm personally not really motivated doing the required builds. We have an
> > > > > > underdeveloped infrastructure which hasn't changed since we abandoned i686 5
> > > > > > years ago.
> > > > > > 
> > > > > > I'd personally like to see more work on our build tooling before we commit to
> > > > > > new architectures.
> > > > > 
> > > > > FYI, it is a single extra command.  Either of these will work...
> > > > > 
> > > > > offload-build --arch x86_64_v3
> > > > > extra-x86_64_v3-build
> > > > > 
> > > > > Nothing else changes for the packager.
> > > > > 
> > > > > Allan
> > > > 
> > > > I'll spend twice as long waiting for a package to build which increases the time
> > > > spent packaging. Which again requires me to spend more time watching stuff fly
> > > > by.
> > > 
> > > I have concerns if that is how you spend your time...  :)
> > > 
> > 
> > I have plenty time left over to ask for pacman backports :) DO NOT WORRY!
> > 
> > 
> > > > This also assumes people are capable of using the buildserver which is not
> > > > always the case either.
> > > > 
> > > > This wasn't great with i686, and I'm not sure why we'd find this acceptable
> > > > today?
> > > 
> > > What was not great with i686?  We managed two architectures for many, many
> > > years.  The reason for removing i686 was to do with outdated technology, not
> > > to do with build times or infrastructure.
> > > 
> > > Do you have objections beyond not wanting to package for both repos? i.e. do
> > > you object to option C in my original email, where we have a team to keep
> > > the repos in sync when package maintainers do not build both?
> > 
> > I'm simply not sure where you are going to get the people for that and how you
> > want to deal with it?
> 
> There is community demand for this port - it will provide benefit for the
> majority of our users.  I'm sure I can find interested parties to join.
> 
> > A *lot* has changed since the x86_64 port. Bringing on people to do these
> > rebuild implies they need access to infrastructure, keyring and so on. And we
> > already have a staff shortage.
> > 
> > I'd like to see some details on how you envision C should be working first.
> 
> Exactly the same as it did in the i686/x86_64 days.  Some packagers will
> upload both variants, some will not.  There was a webpage that showed the
> package differences between the architectures and a group of people built
> and uploaded packages to keep x86_64 in sync.  This was particularly
> important when many devs did not have x86_64 hardware yet.
> 
> We may/will need to recruit some people to do these rebuilds.  The number of
> people needed depends on how many packagers would package for both
> architectures.

This doesn't explain what I wanted to know though.

Are you expecting we find 5-10-20 people and then onboard them as developers or TUs?

Are you envioning a seperate signing keyring, or are you planning on adding them
to the archlinux-keyring?

How are we dealing with access? Do they get full access to our package repos as
devs, or are you planning on a seperate role which has access to the required
repositories? This is relevant because of how dbscripts is deployed on gemini.

All of this requires a fair bit of planning and thought before it's a feasable
option to mention.

-- 
Morten Linderud
PGP: 9C02FF419FECBE16
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20220129/35f67071/attachment.sig>