On Mon, Jan 8, 2018 at 5:16 PM, Adam Williamson
On Mon, 2018-01-08 at 14:40 +0100, Jan Kurik wrote:
> == Scope ==
> * Proposal owners:
> The general AArch64 support is already in place and is widely and
> actively supported by the Fedora ARM SIG and numerous ARM vendors and
> third parties in Fedora. There will be further and wider support,
> hardware enablement, polish and general improvements.
> * Other developers:
> N/A: There's no work required for other developers, the aarch64
> architecture is already widely supported as an Alternate Architecture.
> * Release engineering:
> Needs approval from release engineering as a primary architecture as
> well as pungi configuration changes to output artifacts to new
> location on the primary mirror.
> rel-eng ticket #7243: https://pagure.io/releng/issue/7243
> * Policies and guidelines:
> Updates to the primary architectures and release blocking details will
> need to be updated to reflect that the AArch64 Server/Cloud/Docker
> components are now considered primary.
> * Trademark approval:
> N/A (not needed for this Change)
A significant miss here is 'testing'. Making an arch primary means we
need to ensure we have the necessary resources to run all the relevant
I note pwhalen is a co-owner of the proposal so he's likely signed up
to ensure testing gets done, but still, it should be properly covered
in the Change document itself.
Yes, we've got a bunch of stuff here but the change document template
doesn't really have a good spot to outline all of that.
As a further note, almost all the Server validation for x86_64 is
by openQA; doing it manually can be a considerable pain, as you have to
set up a mini FreeIPA deployment. It would probably be best if we add
aarch64 workers to the Fedora openQA deployment to run these tests on
aarch64; we've already extended openQA (staging) to ppc64, so all the
bits should be in place for us to add another arch, pretty much. I'm
going to follow up on this with pwhalen.
Yes, that is the plan, we have the HW to do it and Paul Whalen has it
running locally, the reason it's not in place already basically comes
down to two things:
1) we needed to wait for the DC migration before we could set some of it up
2) with all the various changes around CI/testing/modularity etc
awaiting to see what the final outcome would be
Another consideration would be whether we ought to also have aarch64
support in Taskotron, if it's going to become a primary arch. I'm not
actually sure if Taskotron currently covers 32-bit ARM, though, even.
That's also on my list, basically we have some hardware, with the
option of more, I had on my list of options:
* auto cloud
* other CI/CD pipelines
* any other options.