Re: F28 System Wide Change: AArch64 Server Promotion

[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
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

F28 System Wide Change: AArch64 Server Promotion

[Matthew Miller]

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 Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

F28 System Wide Change: AArch64 Server Promotion

[Stephen John Smoogen]

On 8 January 2018 at 12:28, Matthew Miller <mattdm(a)fedoraproject.org&gt; 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).

>  --
>  Matthew Miller
>  <mattdm(a)fedoraproject.org&gt;
>  Fedora Project Leader
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org 


-- 
Stephen J Smoogen.

F28 System Wide Change: AArch64 Server Promotion

[Jonathan Dieter]

On Mon, 2018-01-08 at 12:53 -0500, Stephen John Smoogen wrote:
>  On 8 January 2018 at 12:28, Matthew Miller
> <mattdm(a)fedoraproject.org&gt;
>  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

F28 System Wide Change: AArch64 Server Promotion

[Stephen John Smoogen]

On 8 January 2018 at 13:03, Jonathan Dieter <jdieter(a)lesbg.com&gt; wrote:
>  On Mon, 2018-01-08 at 12:53 -0500, Stephen John Smoogen wrote:
> > On 8 January 2018 at 12:28, Matthew Miller <mattdm(a)fedoraproject.org&gt;
> > 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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org 


-- 
Stephen J Smoogen.

F28 System Wide Change: AArch64 Server Promotion

[Adam Williamson]

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 <mattdm(a)fedoraproject.org&gt;
>  > 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

F28 System Wide Change: AArch64 Server Promotion

[Adam Williamson]

On Mon, 2018-01-08 at 12:53 -0500, Stephen John Smoogen wrote:
>  On 8 January 2018 at 12:28, Matthew Miller
> <mattdm(a)fedoraproject.org&gt; 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.. 
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

F28 System Wide Change: AArch64 Server Promotion

[Peter Robinson]

On Mon, Jan 8, 2018 at 5:53 PM, Stephen John Smoogen <smooge(a)gmail.com&gt; wrote:
>  On 8 January 2018 at 12:28, Matthew Miller
> <mattdm(a)fedoraproject.org&gt; 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/

F28 System Wide Change: AArch64 Server Promotion

[Adam Williamson]

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

F28 System Wide Change: AArch64 Server Promotion

[Matthew Miller]

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 Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

F28 System Wide Change: AArch64 Server Promotion

[Dennis Gilmore]

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

F28 System Wide Change: AArch64 Server Promotion

[Peter Robinson]

> > > == 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

F28 System Wide Change: AArch64 Server Promotion

[Peter Robinson]

On Mon, Jan 8, 2018 at 5:16 PM, Adam Williamson
<adamwill(a)fedoraproject.org&gt; 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.

F28 System Wide Change: AArch64 Server Promotion

[Adam Williamson]

On Tue, 2018-01-09 at 03:43 +0000, 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

F28 System Wide Change: AArch64 Server Promotion

[Peter Robinson]

On Tue, Jan 9, 2018 at 3:57 AM, Adam Williamson
<adamwill(a)fedoraproject.org&gt; wrote:
>  On Tue, 2018-01-09 at 03:43 +0000, 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

F28 System Wide Change: AArch64 Server Promotion

[Adam Williamson]

On Tue, 2018-01-09 at 04:09 +0000, Peter Robinson wrote:
>  On Tue, Jan 9, 2018 at 3:57 AM, Adam Williamson
>  <adamwill(a)fedoraproject.org&gt; wrote:
>  > On Tue, 2018-01-09 at 03:43 +0000, 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