On Mon, Jan 8, 2018 at 5:16 PM, Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote: > 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 > validation testing. > > 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 done > 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: * openQA * auto cloud * task-o-tron * other CI/CD pipelines * any other options. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
