Re: F28 System Wide Change: AArch64 Server Promotion
On Tue, 2018-01-09 at 04:09 +, Peter Robinson wrote: > On Tue, Jan 9, 2018 at 3:57 AM, Adam Williamson >wrote: > > On Tue, 2018-01-09 at 03:43 +, Peter Robinson wrote: > > > > > > > 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. > > > > It does have an entire section called "How To Test". > > Fair enough, I was assuming more that was a end user individual as > opposed to CI/CD/infra details I mean, it's a template. Adjust as appropriate. Including the relevant material seems clearly preferable to leaving it out. Anyhoo. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: AArch64 Server Promotion
On Tue, Jan 9, 2018 at 3:57 AM, Adam Williamsonwrote: > On Tue, 2018-01-09 at 03:43 +, Peter Robinson wrote: >> >> > 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. > > It does have an entire section called "How To Test". Fair enough, I was assuming more that was a end user individual as opposed to CI/CD/infra details ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: AArch64 Server Promotion
>> > == 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. >> >> 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. >> >> 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. > > currently taskotron is x86 only. I am not sure what it would take to > extend it beyond x86, it would be a worthwhile investigation. It would > be useful to have all arches in openQA regardless of primary or > secondary status. I would like to see openQA working for aarch64 in > Fedora's instance a hard requirement of this change. I'm fine with that, we already have OpenQA working fine on aarch64 and the only reason it's not yet in the Fedora infra was that we were awaiting on the DC move and the EOL of Fedora 25 to be able to move hardware around. In fact it basically was a hard requirement for myself (and I suspect Paul as well) as basically I'm lazy and would prefer a machine do as much as the testing as humanly possible so I don't have to :-D Peter ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: AArch64 Server Promotion
On Tue, 2018-01-09 at 03:43 +, Peter Robinson wrote: > > > 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. It does have an entire section called "How To Test". -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: AArch64 Server Promotion
On Mon, Jan 8, 2018 at 6:06 PM, Andreas Tunekwrote: > 2018-01-08 19:03 GMT+01:00 Jonathan Dieter : >> On Mon, 2018-01-08 at 12:53 -0500, Stephen John Smoogen wrote: >>> On 8 January 2018 at 12:28, Matthew Miller >>> wrote: >>> > On Mon, Jan 08, 2018 at 09:16:05AM -0800, Adam Williamson wrote: >>> > > 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. >>> > >>> > Are there hardware needs here? (Like, not in the server room but in >>> > QA >>> > team member's hands?) >>> > >>> >>> I would say in both. We would need to make sure we have enough >>> systems >>> which openqa can reliably run on and we need to have some sort of >>> system that testers can get a hand on. That would require a bit of a >>> 'we expect this hardware to work and this is how you buy/get it' from >>> the aarch64 team.. otherwise most everyone is going to come and ask >>> why the raspberry pi 3 isn't supported (just like they did with the >>> raspberry pi 1 and 2.) [I am not looking to rehash why it isn't .. >>> more that is what most testers can get their hands on easily.. and it >>> is not a aarch64 platform we support). >> >> I may be going off in the weeds here, but is https://fedoraproject.org/ >> wiki/Architectures/ARM/Raspberry_Pi#Raspberry_Pi_3_aarch64_support not >> accurate when it says it *is* supported? >> > > That link does not work for me and I get some strange redirect to the > Fedora download page. https://fedoraproject.org/wiki/Architectures/ARM/Raspberry_Pi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: AArch64 Server Promotion
On Mon, Jan 8, 2018 at 6:03 PM, Jonathan Dieterwrote: > On Mon, 2018-01-08 at 12:53 -0500, Stephen John Smoogen wrote: >> On 8 January 2018 at 12:28, Matthew Miller >> wrote: >> > On Mon, Jan 08, 2018 at 09:16:05AM -0800, Adam Williamson wrote: >> > > 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. >> > >> > Are there hardware needs here? (Like, not in the server room but in >> > QA >> > team member's hands?) >> > >> >> I would say in both. We would need to make sure we have enough >> systems >> which openqa can reliably run on and we need to have some sort of >> system that testers can get a hand on. That would require a bit of a >> 'we expect this hardware to work and this is how you buy/get it' from >> the aarch64 team.. otherwise most everyone is going to come and ask >> why the raspberry pi 3 isn't supported (just like they did with the >> raspberry pi 1 and 2.) [I am not looking to rehash why it isn't .. >> more that is what most testers can get their hands on easily.. and it >> is not a aarch64 platform we support). > > I may be going off in the weeds here, but is https://fedoraproject.org/ > wiki/Architectures/ARM/Raspberry_Pi#Raspberry_Pi_3_aarch64_support not > accurate when it says it *is* supported? Nope, it's completely accurate and it's supported ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: AArch64 Server Promotion
On Mon, Jan 8, 2018 at 5:53 PM, Stephen John Smoogenwrote: > On 8 January 2018 at 12:28, Matthew Miller wrote: >> On Mon, Jan 08, 2018 at 09:16:05AM -0800, Adam Williamson wrote: >>> 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. >> >> Are there hardware needs here? (Like, not in the server room but in QA >> team member's hands?) >> > > I would say in both. We would need to make sure we have enough systems > which openqa can reliably run on and we need to have some sort of > system that testers can get a hand on. That would require a bit of a There will be more than enough HW for openQA, we have two large systems we'll put into the cloud (awaiting commissioning now the DC migration is done) which will enable us to use AutoCloud (or what ever it's replacement is) for VM/Docker testing, and a number of physical systems for OpenQA. > 'we expect this hardware to work and this is how you buy/get it' from > the aarch64 team.. otherwise most everyone is going to come and ask > why the raspberry pi 3 isn't supported (just like they did with the The Raspberry Pi 3 *IS* supported on aarch64 [1]! As is the Pine64, currently headless needs a serial console but by F-28 it will be supported with basic console out for HDMI too, We support around 20 aarch64 SBCs in F-27 [1] and I expect that to likely double, or even more than that, with F-28. Along with all the SBSA compliant hardware etc. I have the ability to get HW provided to people that are actually going to use it for testing the problem I have here is that I regularly give people hardware for testing and I get zero testing back and Paul, myself and others still end up doing all the testing. > raspberry pi 1 and 2.) [I am not looking to rehash why it isn't .. > more that is what most testers can get their hands on easily.. and it > is not a aarch64 platform we support). Err, RPi 0-2 are 32 bit only devices in the case of < 2 they're ARMv6, and we support the RPi2 with 32 bit I don't see how any of that is relevant to this conversation? [1] https://nullr0ute.com/2017/11/overview-of-aarch64-sbc-support-in-fedora-27/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: AArch64 Server Promotion
On Mon, Jan 8, 2018 at 5:16 PM, Adam Williamsonwrote: > 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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: AArch64 Server Promotion
On Mon, Jan 08, 2018 at 04:37:34PM -0800, Adam Williamson wrote: > > Are there hardware needs here? (Like, not in the server room but in QA > > team member's hands?) > pwhalen has hardware. Not sure who else does. I'm not going to ask for > any, because it'd just join all my ARM hardware in the Pile Of Boxes I > Never Get Time To Open. If anyone else on the QA team (or Server SIG) has time but *not* the pile of boxes, this is a good time to say something. :) -- Matthew MillerFedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: AArch64 Server Promotion
On Mon, 2018-01-08 at 20:03 +0200, Jonathan Dieter wrote: > On Mon, 2018-01-08 at 12:53 -0500, Stephen John Smoogen wrote: > > On 8 January 2018 at 12:28, Matthew Miller> > wrote: > > > On Mon, Jan 08, 2018 at 09:16:05AM -0800, Adam Williamson wrote: > > > > 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. > > > > > > Are there hardware needs here? (Like, not in the server room but in > > > QA > > > team member's hands?) > > > > > > > I would say in both. We would need to make sure we have enough > > systems > > which openqa can reliably run on and we need to have some sort of > > system that testers can get a hand on. That would require a bit of a > > 'we expect this hardware to work and this is how you buy/get it' from > > the aarch64 team.. otherwise most everyone is going to come and ask > > why the raspberry pi 3 isn't supported (just like they did with the > > raspberry pi 1 and 2.) [I am not looking to rehash why it isn't .. > > more that is what most testers can get their hands on easily.. and it > > is not a aarch64 platform we support). > > I may be going off in the weeds here, but is https://fedoraproject.org/ > wiki/Architectures/ARM/Raspberry_Pi#Raspberry_Pi_3_aarch64_support not > accurate when it says it *is* supported? I'd say it's slightly unclear. So far as *the ARM team* is concerned, they 'support' that hardware, but so far as *anyone else* is concerned, aarch64 has been a secondary arch all this time. No aarch64 image has been considered 'release-blocking', the aarch64 trees / images are published in the fedora-secondary tree (not the fedora tree), etc. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: AArch64 Server Promotion
On Mon, 2018-01-08 at 12:53 -0500, Stephen John Smoogen wrote: > On 8 January 2018 at 12:28, Matthew Millerwrote: > > On Mon, Jan 08, 2018 at 09:16:05AM -0800, Adam Williamson wrote: > > > 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. > > > > Are there hardware needs here? (Like, not in the server room but in QA > > team member's hands?) > > > > I would say in both. We would need to make sure we have enough systems > which openqa can reliably run on and we need to have some sort of > system that testers can get a hand on. That would require a bit of a > 'we expect this hardware to work and this is how you buy/get it' from > the aarch64 team.. pwhalen says we already have hardware available in phx, but I haven't asked him for more details yet. We wouldn't need much to run the necessary tests, really. Enough boxes to run ~8 VMs simultaneously would probably suffice. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: AArch64 Server Promotion
On Mon, 2018-01-08 at 12:28 -0500, Matthew Miller wrote: > On Mon, Jan 08, 2018 at 09:16:05AM -0800, Adam Williamson wrote: > > 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. > > Are there hardware needs here? (Like, not in the server room but in QA > team member's hands?) pwhalen has hardware. Not sure who else does. I'm not going to ask for any, because it'd just join all my ARM hardware in the Pile Of Boxes I Never Get Time To Open. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: AArch64 Server Promotion
On 8 January 2018 at 13:03, Jonathan Dieterwrote: > On Mon, 2018-01-08 at 12:53 -0500, Stephen John Smoogen wrote: >> On 8 January 2018 at 12:28, Matthew Miller >> wrote: >> > On Mon, Jan 08, 2018 at 09:16:05AM -0800, Adam Williamson wrote: >> > > 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. >> > >> > Are there hardware needs here? (Like, not in the server room but in >> > QA >> > team member's hands?) >> > >> >> I would say in both. We would need to make sure we have enough >> systems >> which openqa can reliably run on and we need to have some sort of >> system that testers can get a hand on. That would require a bit of a >> 'we expect this hardware to work and this is how you buy/get it' from >> the aarch64 team.. otherwise most everyone is going to come and ask >> why the raspberry pi 3 isn't supported (just like they did with the >> raspberry pi 1 and 2.) [I am not looking to rehash why it isn't .. >> more that is what most testers can get their hands on easily.. and it >> is not a aarch64 platform we support). > > I may be going off in the weeds here, but is https://fedoraproject.org/ > wiki/Architectures/ARM/Raspberry_Pi#Raspberry_Pi_3_aarch64_support not > accurate when it says it *is* supported? > Well I am off by a year or more on supported hardware and was passing along DUD (Dodgy Unusable Data). That said it would be good to know what hardware that they want testing on.. in case there is something about XYZ hardware which makes it bootable/runnable but more out of luck than anything people want to put effort to fix on. > Jonathan > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: AArch64 Server Promotion
El lun, 08-01-2018 a las 09:16 -0800, Adam Williamson escribió: > 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. > > 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. > > 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. currently taskotron is x86 only. I am not sure what it would take to extend it beyond x86, it would be a worthwhile investigation. It would be useful to have all arches in openQA regardless of primary or secondary status. I would like to see openQA working for aarch64 in Fedora's instance a hard requirement of this change. Dennis signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: AArch64 Server Promotion
On 01/08/2018 01:06 PM, Andreas Tunek wrote: That link does not work for me and I get some strange redirect to the Fedora download page. There was something odd in the link---this works for me: https://fedoraproject.org/wiki/Architectures/ARM/Raspberry_Pi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: AArch64 Server Promotion
2018-01-08 19:03 GMT+01:00 Jonathan Dieter: > On Mon, 2018-01-08 at 12:53 -0500, Stephen John Smoogen wrote: >> On 8 January 2018 at 12:28, Matthew Miller >> wrote: >> > On Mon, Jan 08, 2018 at 09:16:05AM -0800, Adam Williamson wrote: >> > > 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. >> > >> > Are there hardware needs here? (Like, not in the server room but in >> > QA >> > team member's hands?) >> > >> >> I would say in both. We would need to make sure we have enough >> systems >> which openqa can reliably run on and we need to have some sort of >> system that testers can get a hand on. That would require a bit of a >> 'we expect this hardware to work and this is how you buy/get it' from >> the aarch64 team.. otherwise most everyone is going to come and ask >> why the raspberry pi 3 isn't supported (just like they did with the >> raspberry pi 1 and 2.) [I am not looking to rehash why it isn't .. >> more that is what most testers can get their hands on easily.. and it >> is not a aarch64 platform we support). > > I may be going off in the weeds here, but is https://fedoraproject.org/ > wiki/Architectures/ARM/Raspberry_Pi#Raspberry_Pi_3_aarch64_support not > accurate when it says it *is* supported? > That link does not work for me and I get some strange redirect to the Fedora download page. /Andreas Tunek > Jonathan > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: AArch64 Server Promotion
On Mon, 2018-01-08 at 12:53 -0500, Stephen John Smoogen wrote: > On 8 January 2018 at 12:28, Matthew Miller> wrote: > > On Mon, Jan 08, 2018 at 09:16:05AM -0800, Adam Williamson wrote: > > > 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. > > > > Are there hardware needs here? (Like, not in the server room but in > > QA > > team member's hands?) > > > > I would say in both. We would need to make sure we have enough > systems > which openqa can reliably run on and we need to have some sort of > system that testers can get a hand on. That would require a bit of a > 'we expect this hardware to work and this is how you buy/get it' from > the aarch64 team.. otherwise most everyone is going to come and ask > why the raspberry pi 3 isn't supported (just like they did with the > raspberry pi 1 and 2.) [I am not looking to rehash why it isn't .. > more that is what most testers can get their hands on easily.. and it > is not a aarch64 platform we support). I may be going off in the weeds here, but is https://fedoraproject.org/ wiki/Architectures/ARM/Raspberry_Pi#Raspberry_Pi_3_aarch64_support not accurate when it says it *is* supported? Jonathan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: AArch64 Server Promotion
On 8 January 2018 at 12:28, Matthew Millerwrote: > On Mon, Jan 08, 2018 at 09:16:05AM -0800, Adam Williamson wrote: >> 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. > > Are there hardware needs here? (Like, not in the server room but in QA > team member's hands?) > I would say in both. We would need to make sure we have enough systems which openqa can reliably run on and we need to have some sort of system that testers can get a hand on. That would require a bit of a 'we expect this hardware to work and this is how you buy/get it' from the aarch64 team.. otherwise most everyone is going to come and ask why the raspberry pi 3 isn't supported (just like they did with the raspberry pi 1 and 2.) [I am not looking to rehash why it isn't .. more that is what most testers can get their hands on easily.. and it is not a aarch64 platform we support). > -- > Matthew Miller > > Fedora Project Leader > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: AArch64 Server Promotion
On Mon, Jan 08, 2018 at 09:16:05AM -0800, Adam Williamson wrote: > 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. Are there hardware needs here? (Like, not in the server room but in QA team member's hands?) -- Matthew MillerFedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: AArch64 Server Promotion
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. 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. 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. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org