Installation validation test change proposal: merge USB tests into 'default boot and install', add more environment columns

[Adam Williamson]

Hi folks! Sending this to devel@ as well as test@ as there's been some
relevant discussion there recently. We've been kicking around a couple
of issues lately:

1. Exactly what do we need to test and block on, in terms of writing
images to USB sticks?

2. 'Default boot and install' table was supposed to require bare metal
optical media testing at release time, but this is not clear, and
openQA fills in results despite not testing real media on bare metal.

So here's my proposal to address both topics. It involves changes to
the Boot_default_install test:

https://fedoraproject.org/wiki/User:Adamwill/Draft_Testcase_Boot_default_...
https://fedoraproject.org/w/index.php?title=User:Adamwill/Draft_Testcase_...

and the Installation matrix template page:

https://fedoraproject.org/wiki/User:Adamwill/Draft_Installation_test_matrix
https://fedoraproject.org/w/index.php?title=User:Adamwill/Draft_Installat...

to summarize the changes - we improve the test case's wording to give
explicit instructions for all three media types we care about (virtual
disc attached to a VM, real optical disc in a real machine, real USB
stick in a real machine), we ditch the USB test matrices entirely, and
we give the 'Default boot and install' tables extra result columns so
they can now reflect results for VM, CD/DVD and USB testing (for BIOS
and UEFI in all three cases, for x86_64).

I didn't get too finicky about the wording for the virt case, as that's
basically there to get filled in by openQA anyway. For the CD/DVD case,
the test case instructs you to write the disc according to the
'official instructions', with a URL that is supposed to be always
provided by the docs project for that purpose. For the USB case, the
test case instructs you to write the stick according to
https://fedoraproject.org/wiki/How_to_create_and_use_Live_USB , telling
you to use the 'most prominently-recommended method'; the intent being
that, as things stand, we would only block on Fedora Media Writer
issues. I didn't explicitly cover dd (e.g. with separate FMW and dd
columns) for two reasons:

1. It should pretty reliably be the case that if FMW works, dd works
2. Some people are going to test plain dd anyway, it's just such a
convenient 'expert' method that I can't imagine we won't have people
using it throughout the test period

I didn't cover livecd-iso-to-disk because it seems like, overall, the
feedback to cmurf's "F26 proposal: Make Fedora Media Writer the
officially supported USB install media creator" was fairly positive and
I think justifies not guaranteeing testing for it.

To be clear, this is a trade-off between 'in an ideal world we'd test
everything' and 'but we really don't have time'. Each additional method
adds 12 mandatory tests (6 images, both UEFI and BIOS variants of the
test). We can discount the virt tests, as openQA will do those, so in
the proposal, there are 24 mandatory tests for humans; if we added dd
as its own thing there'd be 36, if we added litd as well there'd be 48.

One note is that this doesn't do much to ensure that FMW is working at
release time in all expected environments (probably at least the two
previous stable Fedora releases, macOS, and Windows). On the other
hand, neither does the current matrix; we explicitly list FMW, but we
don't specify what environments it should be run in. We could consider
adding a USB table with a slightly different focus, the idea being to
test the *writing tool* rather than test that the *image* can be
written and works properly. We could make that a follow-up proposal. If
we had such a table, it could maybe cover testing livecd-iso-to-disk's
advanced features as optional tests, or something.

At present I'm not proposing any changes to the *release criteria* (we
can maybe consider that later). This is just a proposal for what we
will actually guarantee testing of via the validation process.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Chris Murphy]

On Fri, Oct 7, 2016 at 2:08 PM, Adam Williamson
<adamwill(a)fedoraproject.org&gt; wrote:
>  Hi folks! Sending this to devel@ as well as test@ as there's been
> some
>  relevant discussion there recently. We've been kicking around a couple
>  of issues lately:
>
>  1. Exactly what do we need to test and block on, in terms of writing
>  images to USB sticks?
>
>  2. 'Default boot and install' table was supposed to require bare metal
>  optical media testing at release time, but this is not clear, and
>  openQA fills in results despite not testing real media on bare metal.
>
>  So here's my proposal to address both topics. It involves changes to
>  the Boot_default_install test:
>
>  https://fedoraproject.org/wiki/User:Adamwill/Draft_Testcase_Boot_default_...
>
> https://fedoraproject.org/w/index.php?title=User:Adamwill/Draft_Testcase_...
>
>  and the Installation matrix template page:
>
>  https://fedoraproject.org/wiki/User:Adamwill/Draft_Installation_test_matrix
>
> https://fedoraproject.org/w/index.php?title=User:Adamwill/Draft_Installat...
>
>  to summarize the changes - we improve the test case's wording to give
>  explicit instructions for all three media types we care about (virtual
>  disc attached to a VM, real optical disc in a real machine, real USB
>  stick in a real machine), we ditch the USB test matrices entirely, and
>  we give the 'Default boot and install' tables extra result columns so
>  they can now reflect results for VM, CD/DVD and USB testing (for BIOS
>  and UEFI in all three cases, for x86_64).
>
>  I didn't get too finicky about the wording for the virt case, as that's
>  basically there to get filled in by openQA anyway. For the CD/DVD case,
>  the test case instructs you to write the disc according to the
>  'official instructions', with a URL that is supposed to be always
>  provided by the docs project for that purpose. For the USB case, the
>  test case instructs you to write the stick according to
>  https://fedoraproject.org/wiki/How_to_create_and_use_Live_USB , telling
>  you to use the 'most prominently-recommended method'; the intent being
>  that, as things stand, we would only block on Fedora Media Writer
>  issues. I didn't explicitly cover dd (e.g. with separate FMW and dd
>  columns) for two reasons:
>
>  1. It should pretty reliably be the case that if FMW works, dd works
>  2. Some people are going to test plain dd anyway, it's just such a
>  convenient 'expert' method that I can't imagine we won't have people
>  using it throughout the test period
>
>  I didn't cover livecd-iso-to-disk because it seems like, overall, the
>  feedback to cmurf's "F26 proposal: Make Fedora Media Writer the
>  officially supported USB install media creator" was fairly positive and
>  I think justifies not guaranteeing testing for it.
>
>  To be clear, this is a trade-off between 'in an ideal world we'd test
>  everything' and 'but we really don't have time'. Each additional method
>  adds 12 mandatory tests (6 images, both UEFI and BIOS variants of the
>  test). We can discount the virt tests, as openQA will do those, so in
>  the proposal, there are 24 mandatory tests for humans; if we added dd
>  as its own thing there'd be 36, if we added litd as well there'd be 48.
>
>  One note is that this doesn't do much to ensure that FMW is working at
>  release time in all expected environments (probably at least the two
>  previous stable Fedora releases, macOS, and Windows). On the other
>  hand, neither does the current matrix; we explicitly list FMW, but we
>  don't specify what environments it should be run in. We could consider
>  adding a USB table with a slightly different focus, the idea being to
>  test the *writing tool* rather than test that the *image* can be
>  written and works properly. We could make that a follow-up proposal. If
>  we had such a table, it could maybe cover testing livecd-iso-to-disk's
>  advanced features as optional tests, or something.
>
>  At present I'm not proposing any changes to the *release criteria* (we
>  can maybe consider that later). This is just a proposal for what we
>  will actually guarantee testing of via the validation process. 

Looks and sounds good to me.

-- 
Chris Murphy

[Kevin Kofler]

Adam Williamson wrote:
>  to summarize the changes - we improve the test case's wording to
> give
>  explicit instructions for all three media types we care about (virtual
>  disc attached to a VM, real optical disc in a real machine, real USB
>  stick in a real machine), we ditch the USB test matrices entirely, and
>  we give the 'Default boot and install' tables extra result columns so
>  they can now reflect results for VM, CD/DVD and USB testing (for BIOS
>  and UEFI in all three cases, for x86_64). 
You can actually test in a VM both as a virtual CD/DVD:

-cdrom file
  Use file as CD-ROM image (you cannot use -hdc and -cdrom at the same
  time). You can use the host CD-ROM by using /dev/cdrom as filename.

and as a virtual USB:

-usbdevice devname
  Add the USB device devname. 

  disk:[format=format]:file
    Mass storage device based on file. The optional format argument will be
    used rather than detecting the format. Can be used to specifiy
    "format=raw" to avoid interpreting an untrusted format header.

(The quotes are from the qemu manpage.)

It is not a replacement for testing on real hardware, but it could catch at 
least some of the differences.

        Kevin Kofler

[Adam Williamson]

On Sat, 2016-10-08 at 14:50 +0200, Kevin Kofler wrote:
>  Adam Williamson wrote:
>  > to summarize the changes - we improve the test case's wording to give
>  > explicit instructions for all three media types we care about (virtual
>  > disc attached to a VM, real optical disc in a real machine, real USB
>  > stick in a real machine), we ditch the USB test matrices entirely, and
>  > we give the 'Default boot and install' tables extra result columns so
>  > they can now reflect results for VM, CD/DVD and USB testing (for BIOS
>  > and UEFI in all three cases, for x86_64).
>  
>  
>  You can actually test in a VM both as a virtual CD/DVD:
>  
>  -cdrom file
>    Use file as CD-ROM image (you cannot use -hdc and -cdrom at the same
>    time). You can use the host CD-ROM by using /dev/cdrom as filename.
>  
>  and as a virtual USB:
>  
>  -usbdevice devname
>    Add the USB device devname. 
>  
>    disk:[format=format]:file
>      Mass storage device based on file. The optional format argument will be
>      used rather than detecting the format. Can be used to specifiy
>      "format=raw" to avoid interpreting an untrusted format header.
>  
>  (The quotes are from the qemu manpage.)
>  
>  It is not a replacement for testing on real hardware, but it could catch at 
>  least some of the differences. 
Yeah, I know, I've been meaning to add an openQA test that does the
latter but not really got around to it. It didn't seem worth adding an
extra result column pair for 'virt USB' (vs 'virt CD') though...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Kamil Paral]

>  Hi folks! Sending this to devel@ as well as test@ as there's been
> some
>  relevant discussion there recently. We've been kicking around a couple
>  of issues lately:
>  
>  1. Exactly what do we need to test and block on, in terms of writing
>  images to USB sticks?
>  
>  2. 'Default boot and install' table was supposed to require bare metal
>  optical media testing at release time, but this is not clear, and
>  openQA fills in results despite not testing real media on bare metal.
>  
>  So here's my proposal to address both topics. It involves changes to
>  the Boot_default_install test:
>  
>  https://fedoraproject.org/wiki/User:Adamwill/Draft_Testcase_Boot_default_...
>
> https://fedoraproject.org/w/index.php?title=User:Adamwill/Draft_Testcase_...
>  
>  and the Installation matrix template page:
>  
>  https://fedoraproject.org/wiki/User:Adamwill/Draft_Installation_test_matrix
>
> https://fedoraproject.org/w/index.php?title=User:Adamwill/Draft_Installat...
>  
>  to summarize the changes - we improve the test case's wording to give
>  explicit instructions for all three media types we care about (virtual
>  disc attached to a VM, real optical disc in a real machine, real USB
>  stick in a real machine), we ditch the USB test matrices entirely, and
>  we give the 'Default boot and install' tables extra result columns so
>  they can now reflect results for VM, CD/DVD and USB testing (for BIOS
>  and UEFI in all three cases, for x86_64). 
It's a lot of empty fields, which can't be automated by definition. The new matrix
version seems to be more time consuming that the previous version. I wonder what we can do
to cut down the time spent on this. Here are a few ideas:

a) could we decouple boot from install?

I know we've had a few problems in the past that occurred only on bare metal and not
in VMs. But do I remember correctly that all of those were related to booting the
installer/live system, and not the installation? What we do here is that we repeat the
default installation over and over again, e.g. Workstation Live using BIOS and UEFI (which
results in a slightly different partition layout), from different sources (DVD in VM, DVD
on bare metal, USB). But do those environments (VM vs bare metal, DVD vs USB) actually
matter, is there a good reason to repeat them that many times? What if we reduce all of
this to:

Default install
===============
                        Result
Workstation Live         [ ]
Workstation netinst      [ ]
Everything netinst       [ ]
Server netinst           [ ]
Server DVD               [ ]
KDE Live                 [ ]

which would be satisfiable using ANY environment and it would just check that anaconda can
use that particular installation source correctly? The BIOS vs UEFI partitioning is
already covered thoroughly in the "Guided storage configuration" table.

The currently proposed "Default boot and install" section would stay the same,
but be renamed to "Default boot" and would just check that the image *boots*
into the installer in that particular environment.


b) do we need to insist on performing the *default* install?

If the previous idea doesn't fly, this is another way to improve testing time. For
example, we're installing the Server package set 12 times in the currently proposed
table ((Server DVD + Server netinst) * environments). Is that really necessary? What if we
did it once (in any environment), and then could do just a minimal install the remaining
11 times? Because installation takes most of the time here, esp. from optical media. And I
can't imagine how the environments could differ in such a way that would break default
installation set just in a particular environment but not a different installation set in
the same environment (esp. when heavily pushing dd-like based approach).

So again we would have a table like this:

Default package set
===================
                        Result
Workstation netinst      [ ]
Server netinst           [ ]
Server DVD               [ ]

which would be satisfiable in any environment (we already have "Package sets"
section in which this would fit nicely), and in the "Default boot and install"
table you could choose a different package set for installation. We could go even further
and allow arbitrary partitioning to be used in "Default boot and install", so
that it can be combined with our partitioning test cases. Again, that would allow us to
test multiple features together and save time, while not sacrificing the core thing to
test here (running the particular medium in a particular environment).


>  
>  I didn't get too finicky about the wording for the virt case, as that's
>  basically there to get filled in by openQA anyway. For the CD/DVD case,
>  the test case instructs you to write the disc according to the
>  'official instructions', with a URL that is supposed to be always
>  provided by the docs project for that purpose. For the USB case, the
>  test case instructs you to write the stick according to
>  https://fedoraproject.org/wiki/How_to_create_and_use_Live_USB , telling
>  you to use the 'most prominently-recommended method'; the intent being
>  that, as things stand, we would only block on Fedora Media Writer
>  issues. I didn't explicitly cover dd (e.g. with separate FMW and dd
>  columns) for two reasons:
>  
>  1. It should pretty reliably be the case that if FMW works, dd works
>  2. Some people are going to test plain dd anyway, it's just such a
>  convenient 'expert' method that I can't imagine we won't have people
>  using it throughout the test period
>  
>  I didn't cover livecd-iso-to-disk because it seems like, overall, the
>  feedback to cmurf's "F26 proposal: Make Fedora Media Writer the
>  officially supported USB install media creator" was fairly positive and
>  I think justifies not guaranteeing testing for it. 
All of that sounds fine to me.

>  
>  To be clear, this is a trade-off between 'in an ideal world we'd test
>  everything' and 'but we really don't have time'. Each additional method
>  adds 12 mandatory tests (6 images, both UEFI and BIOS variants of the
>  test). We can discount the virt tests, as openQA will do those, so in
>  the proposal, there are 24 mandatory tests for humans; if we added dd
>  as its own thing there'd be 36, if we added litd as well there'd be 48.
>  
>  One note is that this doesn't do much to ensure that FMW is working at
>  release time in all expected environments (probably at least the two
>  previous stable Fedora releases, macOS, and Windows). On the other
>  hand, neither does the current matrix; we explicitly list FMW, but we
>  don't specify what environments it should be run in. We could consider
>  adding a USB table with a slightly different focus, the idea being to
>  test the *writing tool* rather than test that the *image* can be
>  written and works properly. We could make that a follow-up proposal. If
>  we had such a table, it could maybe cover testing livecd-iso-to-disk's
>  advanced features as optional tests, or something. 
Makes sense.

>  
>  At present I'm not proposing any changes to the *release criteria* (we
>  can maybe consider that later). This is just a proposal for what we
>  will actually guarantee testing of via the validation process. 
If we go full steam ahead with optical disk testing as proposed (in the past, the
"default boot and install" test case said you can choose either USB or DVD, now
we have separate fields for both implying we need to test both) I'd suggest optical
media being only in the Final criteria.

[Matthew Miller]

On Fri, Oct 07, 2016 at 01:08:13PM -0700, Adam Williamson wrote:
>  explicit instructions for all three media types we care about
> (virtual
>  disc attached to a VM, real optical disc in a real machine, real USB
>  stick in a real machine), we ditch the USB test matrices entirely, and 
I think we should plan to drop out real optical disks sometime in the
next couple releases. (In line with "'in an ideal world we'd test
everything' and 'but we really don't have time'".) I think the
hardware
on which Fedora will run well which cannot boot from USB media is
vanishingly small.



-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Adam Williamson]

On Mon, 2016-10-10 at 11:42 -0400, Matthew Miller wrote:
>  On Fri, Oct 07, 2016 at 01:08:13PM -0700, Adam Williamson wrote:
>  > explicit instructions for all three media types we care about (virtual
>  > disc attached to a VM, real optical disc in a real machine, real USB
>  > stick in a real machine), we ditch the USB test matrices entirely, and
>  
>  
>  I think we should plan to drop out real optical disks sometime in the
>  next couple releases. (In line with "'in an ideal world we'd test
>  everything' and 'but we really don't have time'".) I think the
> hardware
>  on which Fedora will run well which cannot boot from USB media is
>  vanishingly small. 
Well, that's not the only consideration though. There's two other
factors I can think of:

1) Are there still cases where an admin would want to use optical media
on a machine that *could* boot via USB, for legitimate reasons? (I
genuinely don't know the answer to this).

2) What do we do about handouts (giving away media at conferences)?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Kevin Kofler]

Adam Williamson wrote:
>  1) Are there still cases where an admin would want to use optical
> media
>  on a machine that *could* boot via USB, for legitimate reasons? (I
>  genuinely don't know the answer to this). 
Is "I have a spare DVD±R around, but no spare USB key" enough of a reason? 
(That was my case recently.)

        Kevin Kofler

[Matthew Miller]

On Mon, Oct 10, 2016 at 09:03:44PM +0200, Kevin Kofler wrote:
>  > 1) Are there still cases where an admin would want to use
> optical media
>  > on a machine that *could* boot via USB, for legitimate reasons? (I
>  > genuinely don't know the answer to this).
>  Is "I have a spare DVD±R around, but no spare USB key" enough of a reason? 
>  (That was my case recently.) 
I think that's also likely to be rapidly diminishing case.

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Matthew Miller]

On Mon, Oct 10, 2016 at 08:58:43AM -0700, Adam Williamson wrote:
>  Well, that's not the only consideration though. There's two
> other
>  factors I can think of:
>  1) Are there still cases where an admin would want to use optical media
>  on a machine that *could* boot via USB, for legitimate reasons? (I
>  genuinely don't know the answer to this). 
I can't think of in the Fedora case. I can image some situations where
install media is mandated to be read-only, but I doubt it's Fedora
being installed in those situations. The only other one I can think of
is "we've always done it that way", which I guess shouldn't be taken
completely for granted.


>  2) What do we do about handouts (giving away media at conferences)?
This is already a problem. We're giving away DVDs because it's
something to give away, not because it's what people really still want.
We need to find out some other take-homes that people find
useful and desirable *anyway*.

Based on feedback from Ambassadors, DVD images may still be useful
giveaways in regions with less access to bandwidth. I'm not sure what
to do about that.

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Kevin Kofler]

Matthew Miller wrote:
>  This is already a problem. We're giving away DVDs because
> it's
>  something to give away, not because it's what people really still want.
>  We need to find out some other take-homes that people find
>  useful and desirable *anyway*.
>  
>  Based on feedback from Ambassadors, DVD images may still be useful
>  giveaways in regions with less access to bandwidth. I'm not sure what
>  to do about that. 
My experience from the yearly Vienna Linux Week is that demand for DVDs has 
been dropping significantly for the last couple years. It was still high for 
1-2 years when the demand in the US had already dropped, but notebooks 
without an optical drive have since become commonplace here too. (You CAN 
still get a notebook with an optical drive if you really want around here, 
but it is not the standard anymore.) That said, the demand might still be 
non-zero. We did not have any Fedora media to give out this year (there 
wasn't even a Fedora stand due to lack of personnel), so I do not have 
precise data from this year.

What would be really great would be USB keys to hand out, but I guess the 
prices for those are still too prohibitive. "USB burning stations" have also 
not worked out all that well when they were tried at various events in the 
past, though it might be worth retrying that these days. Having a reliable 
nondestructive way to transfer Fedora onto a USB key would help there, 
though. At least I really wouldn't feel well about just erasing every USB 
stick I am handed over, nor would I have the time to check every stick I am 
given with the owner (nor would I want to peek around in the owner's data to 
begin with).

        Kevin Kofler

[Thomas Gilliard]

On 10/10/2016 03:48 PM, Kevin Kofler wrote:
>  Matthew Miller wrote:
> > This is already a problem. We're giving away DVDs because it's
> > something to give away, not because it's what people really still want.
> > We need to find out some other take-homes that people find
> > useful and desirable *anyway*.
> >
> > Based on feedback from Ambassadors, DVD images may still be useful
> > giveaways in regions with less access to bandwidth. I'm not sure what
> > to do about that.
>  My experience from the yearly Vienna Linux Week is that demand for DVDs has
>  been dropping significantly for the last couple years. It was still high for
>  1-2 years when the demand in the US had already dropped, but notebooks
>  without an optical drive have since become commonplace here too. (You CAN
>  still get a notebook with an optical drive if you really want around here,
>  but it is not the standard anymore.) That said, the demand might still be
>  non-zero. We did not have any Fedora media to give out this year (there
>  wasn't even a Fedora stand due to lack of personnel), so I do not have
>  precise data from this year.
>
>  What would be really great would be USB keys to hand out, but I guess the
>  prices for those are still too prohibitive. "USB burning stations" have also
>  not worked out all that well when they were tried at various events in the
>  past, though it might be worth retrying that these days. Having a reliable
>  nondestructive way to transfer Fedora onto a USB key would help there,
>  though. At least I really wouldn't feel well about just erasing every USB
>  stick I am handed over, nor would I have the time to check every stick I am
>  given with the owner (nor would I want to peek around in the owner's data to
>  begin with).
>
>           Kevin Kofler 
This sounds like a use for https://wiki.gnome.org/Apps/MultiWriter
let the people bring their own USB keys
satellit
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org

[Kevin Kofler]

Thomas Gilliard wrote:
>  This sounds like a use for https://wiki.gnome.org/Apps/MultiWriter
>  let the people bring their own USB keys 
I already mentioned this sort of tool ("USB burning stations" – most of them 
were actually notebooks running software like this). It doesn't solve the 
problem that the operation is destructive and you cannot trust the user to 
not hand you in a key with important data and then blame you for destroying 
it (and then you have to prove that you actually warned them, and even if 
you can prove it, it won't keep the user from destroying your reputation).

        Kevin Kofler

[Chris Murphy]

On Mon, Oct 10, 2016 at 2:59 PM, Matthew Miller
<mattdm(a)fedoraproject.org&gt; wrote:

>  Based on feedback from Ambassadors, DVD images may still be useful
>  giveaways in regions with less access to bandwidth. I'm not sure what
>  to do about that. 
U.S. rural areas? :-D

Are we talking about the DVDs being useful in areas with no internet
at all, or just slow internet? And would an optical specific Live
Workstation spin for Ambassadors be a useful work around?


-- 
Chris Murphy

[Matthew Miller]

On Mon, Oct 10, 2016 at 10:00:05PM -0600, Chris Murphy wrote:
>  > Based on feedback from Ambassadors, DVD images may still be
> useful
>  > giveaways in regions with less access to bandwidth. I'm not sure what
>  > to do about that.
>  U.S. rural areas? :-D 
Possibly, although I think most people would be able to get to
somewhere were downloading a gigabyte or so wouldn't be a big deal.

>  Are we talking about the DVDs being useful in areas with no internet
>  at all, or just slow internet? 
I was thinking no internet or expensive metered connections. Slow...
eh, I downloaded djgpp over a second-hand 1200 baud modem in the early
90s. Kids today can set it a Fedora download overnight. :)

>  And would an optical specific Live Workstation spin for Ambassadors
>  be a useful work around? 
I think so.

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[DJ Delorie]

>  U.S. rural areas? :-D 
I'm pretty rural, and even I have good internet.  Maybe we need to
redefine "rural" to be independent of physicality :-)

>  Based on feedback from Ambassadors, DVD images may still be useful
>  giveaways in regions with less access to bandwidth. I'm not sure what
>  to do about that. 
Having been through the "mail disks" end of things myself, I can agree
that having *some* way of bulk transferring data to people in need is,
if not mandatory, at least very useful.  However, I would condition that
with "any method that works" - it doesn't need to be an installable
image, for example, as long as the recipient can use it locally to do an
install somehow (for example, a split-up directory tree that, when
combined, makes an nfs-installable repo, would be sufficient).

We'd need to consider how often such disks are needed vs the effort of
making them "pretty" on our end.  For example, if an Ambassador can use
their laptop, or a USB stick, to bootstrap an install (i.e. at an
installfest), then use that machine to install to others... etc.

Just saying, while a cd/dvd/bluray is the easiest thing to mail, it's
not the only option to enable those folks.  We need to balance
stack-of-cds vs bluray vs usbstick vs laptop vs effort on our end vs
what the actual problem is (i.e. "test Fedora" vs "local full repo").

(personally, I think a bootable USB is much more useful than an
installable disc, as long as the USB can store user data and thus not be
transient, but I too have a few older machines that can't boot USB)

>  I downloaded djgpp over a second-hand 1200 baud modem in the early
> 90s. 
Me too.  Oh wait... ;-)

[Chris Murphy]

On Tue, Oct 11, 2016 at 12:41 PM, DJ Delorie <dj(a)redhat.com&gt; wrote:
> > U.S. rural areas? :-D
>
>  I'm pretty rural, and even I have good internet.  Maybe we need to
>  redefine "rural" to be independent of physicality :-) 
Yes it was sort of a ding on the state of affairs in the U.S. rather
than rural areas. U.S. bandwidth increases aren't keeping up with the
rest of the world, even including urban areas let alone excluding them
from the metric. And I'm in a rural area with ~18Mbps usually but it
varies below that sometimes by quite a bit, as low as 2Mbps.

So if the context is 2Mbps or less, I'd think people would get
frustrated fairly quickly with the ~ 1GiB+ downloads Gnome Software
does in the background on first boot, with no UI for disabling it.
Those without internet wouldn't have this problem of course. But they
get hit with a higher percent of unfixed bugs, even known bugs, that
just weren't bad enough to be blockers.

Another idea might be merging the optical media use case with another
one that already exists and has testers who might be in a position to
maintain working optical boot: Live respins.
http://dl.fedoraproject.org/pub/alt/live-respins/  This group is
making up to date Lives, so there's far less stale stuff with more bug
fixes than the official media.


-- 
Chris Murphy

[Kevin Kofler]

Chris Murphy wrote:
>  So if the context is 2Mbps or less, I'd think people would get
>  frustrated fairly quickly with the ~ 1GiB+ downloads Gnome Software
>  does in the background on first boot, with no UI for disabling it. 
That is just unacceptable behavior from GNOME Software and ought to be 
fixed. plasma-pk-updates does not download anything you haven't asked for.

        Kevin Kofler

[Alexander Ploumistos]

On Mon, Oct 10, 2016 at 6:58 PM, Adam Williamson
<adamwill(a)fedoraproject.org&gt; wrote:
>  1) Are there still cases where an admin would want to use optical
> media
>  on a machine that *could* boot via USB, for legitimate reasons? (I
>  genuinely don't know the answer to this). 
So far I've had to deal with three small factor PCs with not enough
USB ports and no PS/2 ports for mouse and keyboard. One of them needed
a USB port for a GSM dongle, the other for a WiFi adapter and the
third for a USB2Ethernet adapter. All of them had optical drives. I
did an offline installation for two of them and the other without a
mouse. Had I known beforehand, I would have taken a hub with me, or a
DVD. Also, on some systems, not all USB ports can be used at boot;
they do have power, but no data signals- I don't know why, could be a
firmware issue, but only some of them function around POST.
Afterwards, they work normally. In most such cases, not having a DVD
is an inconvenience, but not an insurmountable one.

>  2) What do we do about handouts (giving away media at conferences)?
There are many dirt cheap flash drives around, with painfully low
write speeds, almost decent read speeds and when they are not DOA,
they can usually survive an installfest. On the plus side, they can be
ordered with a fedora logo or engraving at no extra cost.

[John Florian]

On Mon, 2016-10-10 at 11:42 -0400, Matthew Miller wrote:

 I think the hardware on which Fedora will run well which cannot boot from USB media is
vanishingly small.


Like the piece of crap Samsung notebook I bought new in 2012.  [:-/] ​

Using optical media feels so dirty, though I guess it does give me an excuse to use up
that tower of blank discs.  Thank goodness for in-place Fedora upgrades.

--

John Florian <[e-mail]<mailto:[e-mail]>>

[Chris Murphy]

On Mon, Oct 10, 2016 at 9:42 AM, Matthew Miller
<mattdm(a)fedoraproject.org&gt; wrote:
>  On Fri, Oct 07, 2016 at 01:08:13PM -0700, Adam Williamson wrote:
> > explicit instructions for all three media types we care about (virtual
> > disc attached to a VM, real optical disc in a real machine, real USB
> > stick in a real machine), we ditch the USB test matrices entirely, and
>
>  I think we should plan to drop out real optical disks sometime in the
>  next couple releases. (In line with "'in an ideal world we'd test
>  everything' and 'but we really don't have time'".) I think the
> hardware
>  on which Fedora will run well which cannot boot from USB media is
>  vanishingly small. 
Quitting cold turkey sounds better than switching from active to
passive testing (only block if someone finds a failure), because all
it takes to block release is a last minute "can't boot this" bug.

Maybe it's practical to only support optical boot on either Lives or
netinstalls (and by extension server DVD). I'd say block on
netinstalls, just becase those can fit on either a DVD or CD, and
desktops and servers are more likely to still have optical drives.
Laptops just don't anymore for the most part. Part of why is dropping
DVD playback support in Windows 8 and 10. To get DVD playback support
now you have to buy the software separate from the OS. Licensing fees.

-- 
Chris Murphy

[Matthew Miller]

On Mon, Oct 10, 2016 at 12:57:30PM -0600, Chris Murphy wrote:
>  Maybe it's practical to only support optical boot on either Lives
> or
>  netinstalls (and by extension server DVD). I'd say block on
>  netinstalls, just becase those can fit on either a DVD or CD, and
>  desktops and servers are more likely to still have optical drives. 
That works for me as long as we can figure out how to message it.

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader