Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/Drop_Optical_Media_Criterion

= Drop Optical Media Release Criterion =

== Summary ==
Proposal to make all Fedora optical media non-blocking. This means
we'd stop blocking on bugs found during the installation of Fedora
from optical media (like CDs and DVDs). This doesn't mean that
installation from optical media would stop working, just that the
Fedora Release wouldn't be blocked on any issues that can pop up in
Fedora installation using this method. Installation from USB devices
will remain blocking.

== Owner ==
* Name: [[User:frantisekz| František Zatloukal]]
* Email: fzatlouk(a)redhat.com

== Detailed Description ==

We are currently blocking Fedora Release on bugs specific to
installation from optical media. It seems wise to believe that only a
fraction of user base installs Fedora from Optical Media rather than
USB drive. New computers and laptops are usually sold without CD/DVD
drives and installation from optical media takes longer and is prone
to errors more compared to the installation using USB drive.

This change would make following images non-blocking for installation
from optical media:

* <code>Fedora-Everything-netinst-x86_64-_RELEASE_MILESTONE_.iso</code>

* <code>Fedora-Workstation-Live-x86_64-_RELEASE_MILESTONE_.iso</code>

== Benefit to Fedora ==

Fedora QE Team and testers from community will have more time to test
parts of Fedora that are far more visible and exposed to end users.

Fedora QE Team would have more time to add and test additional
high-profile blocking deliverables (like Fedora Silverblue) in near
future.

Fedora Releases wouldn't be held by bugs found in corner case
installation method.

== Scope ==
* Proposal owners: Change [[Releases/32/ReleaseBlocking]] to indicate
we no longer block on optical media, change Validation Testing
Matrices

* Other developers: No involvement by other developers needed

* Release engineering: https://pagure.io/releng/issue/9097

* Policies and guidelines: No changes needed

* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
No change for upgrades/compatibility

== How To Test ==
Testing not applicable (this change shouldn't result in any changes to
the distribution)

== User Experience ==
Users installing Fedora from optical media might hit some bugs and
might not be able to complete Fedora installation using Optical Media
at all. Such bugs will be treated like other non blocking bugs.

== Dependencies ==
N/A

== Contingency Plan ==

* Contingency mechanism: Revert changes to indicate we block on
optical media again
* Contingency deadline: Final Freeze
* Blocks release? No
* Blocks product? No

== Documentation ==
N/A




-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis

[Adam Williamson]

On Thu, 2019-12-12 at 15:37 -0500, Ben Cotton wrote:
>  
>  == Scope ==
>  * Proposal owners: Change [[Releases/32/ReleaseBlocking]] to indicate
>  we no longer block on optical media, change Validation Testing
>  Matrices 
I don't think this is quite right. The ReleaseBlocking page would
likely not change, as the *images* themselves would remain release
blocking, we just would no longer block on them working when written to
physical optical media.

Rather, as well as the Installation matrix, this would require changing
the release criteria, specifically 'Supported media types' for this
Final criterion:

https://fedoraproject.org/wiki/Fedora_32_Final_Release_Criteria#Release-b...

As a general note, I'm a bit surprised that this popped up as a Change,
though it's not necessarily a problem. Previous changes of this nature
have been handled via the test@ list as release criteria change
proposals, not as Changes: this does not involve any change to the
distribution itself, only to our validation of it.

For context, we changed this most recently in 2017, when the optical
requirement was moved from Alpha (which existed at the time) to Final.
The proposal to drop the optical requirement entirely was first floated
by Matthew Miller in September 2018 on test@ , and there is a long
discussion thread following that proposal:

https://lists.fedoraproject.org/archives/list/[e-mail]...

which may be helpful for context.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Frantisek Zatloukal]

On Thu, Dec 12, 2019 at 11:31 PM Adam Williamson <adamwill(a)fedoraproject.org&gt;
wrote:

>  On Thu, 2019-12-12 at 15:37 -0500, Ben Cotton wrote:
>  >
>  > == Scope ==
>  > * Proposal owners: Change [[Releases/32/ReleaseBlocking]] to indicate
>  > we no longer block on optical media, change Validation Testing
>  > Matrices
>
>  I don't think this is quite right. The ReleaseBlocking page would
>  likely not change, as the *images* themselves would remain release
>  blocking, we just would no longer block on them working when written to
>  physical optical media.
>
>  Rather, as well as the Installation matrix, this would require changing
>  the release criteria, specifically 'Supported media types' for this
>  Final criterion:
>
>
>
> https://fedoraproject.org/wiki/Fedora_32_Final_Release_Criteria#Release-b...
>
>  Proposal updated to reflect Final Release Criteria page change. Thanks, as 
for the 
ReleaseBlocking page, there is "optical boot is release blocking"
column with "yes" for mentioned images, which would change to "no",
should
this change be accepted.


>  The proposal to drop the optical requirement entirely was first
> floated
>  by Matthew Miller in September 2018 on test@ , and there is a long
>  discussion thread following that proposal:
>
>
>
> https://lists.fedoraproject.org/archives/list/[e-mail]...
>
>  which may be helpful for context.
>
>  
Link to the thread has been added to the proposal page.

[Richard Shaw]

Ok, obvious question first... Has this caused any problems? When was the
last time this failed?

The latter part is for selfish reasons... I still have one (decent)
computer with primitive EFI BIOS that will only boot UEFI from optical
media, not from USB (weird, I know).

Thanks,
Richard

[Chris Murphy]

On Thu, Dec 12, 2019 at 7:00 PM Richard Shaw <hobbes1069(a)gmail.com&gt; wrote:
>  Ok, obvious question first... Has this caused any problems? When was the last time this
> failed? 
Funny you should ask. Today!

https://bugzilla.redhat.com/show_bug.cgi?id=1783066

But before that, I think it's been a little while. Couple years?


-- 
Chris Murphy

[John M. Harris Jr]

On Thursday, December 12, 2019 7:12:40 PM MST Chris Murphy wrote:
>  On Thu, Dec 12, 2019 at 7:00 PM Richard Shaw
> <hobbes1069(a)gmail.com&gt; wrote:
>  
>  >
>  >
>  > Ok, obvious question first... Has this caused any problems? When was the
>  > last time this failed?
>  
>  Funny you should ask. Today!
>  
>  https://bugzilla.redhat.com/show_bug.cgi?id=1783066
>  
>  But before that, I think it's been a little while. Couple years? 
This looks like a change in util-linux that we need to adapt to. This is not a 
reason to drop optical media, in my opinion. Many systems, including the 
environment that I support both at Splentity and my employer require optical 
media. Even several of my personal servers also require optical media images 
to be able to re-image systems over their out-of-band control modules.

As mentioned above in this thread, there are a number of systems with BIOS or 
UEFI implementations that don't support booting from USB media to begin with, 
so the workaround suggested is not viable.

-- 
John M. Harris, Jr.
Splentity

[Chris Murphy]

On Thu, Dec 12, 2019 at 9:07 PM John M. Harris Jr <johnmh(a)splentity.com&gt; wrote:
>  On Thursday, December 12, 2019 7:12:40 PM MST Chris Murphy wrote:
>  > On Thu, Dec 12, 2019 at 7:00 PM Richard Shaw <hobbes1069(a)gmail.com&gt; wrote:
>  >
>  > >
>  > >
>  > > Ok, obvious question first... Has this caused any problems? When was the
>  > > last time this failed?
>  >
>  > Funny you should ask. Today!
>  >
>  > https://bugzilla.redhat.com/show_bug.cgi?id=1783066
>  >
>  > But before that, I think it's been a little while. Couple years?
>
>  This looks like a change in util-linux that we need to adapt to. This is not a
>  reason to drop optical media, in my opinion. Many systems, including the
>  environment that I support both at Splentity and my employer require optical
>  media. Even several of my personal servers also require optical media images
>  to be able to re-image systems over their out-of-band control modules. 
Optical media is not being dropped. The proposal expressly says this.

>  As mentioned above in this thread, there are a number of systems with
> BIOS or
>  UEFI implementations that don't support booting from USB media to begin with,
>  so the workaround suggested is not viable. 
The work around is part of testing the scope of the bug. It's not a
prescription for production use.

This bug was caught by openqa bots being unable to boot any of the
rawhide compose images; and last time I recall an ISO related bug
that only affected optical, it was a syslinux/isolinux bug and
likewise tripped up VM's (the qemu cd-rom device). So as an early
warning detection, that's pretty cool. No coasters were made as part
of these tests!

We'll just have to see if there's an easy fix for the util-linux
commit that broke this, which is kinda what I'm expecting. But it
might be reasonable to have one specific optical media only image,
perhaps Everything ISO. And then simplify the other images.


--
Chris Murphy

[John M. Harris Jr]

On Thursday, December 12, 2019 10:52:15 PM MST Chris Murphy wrote:
>  The work around is part of testing the scope of the bug. It's not
> a
>  prescription for production use. 
This is precisely why I believe that optical media should continue to be 
release blocking.

[snip]

>  We'll just have to see if there's an easy fix for the
> util-linux
>  commit that broke this, which is kinda what I'm expecting. But it
>  might be reasonable to have one specific optical media only image,
>  perhaps Everything ISO. And then simplify the other images. 
That would needlessly make it more complex than necessary to install from 
optical media.

-- 
John M. Harris, Jr.
Splentity

[Chris Murphy]

On Fri, Dec 13, 2019 at 10:24 AM John M. Harris Jr <johnmh(a)splentity.com&gt; wrote:
>  On Thursday, December 12, 2019 10:52:15 PM MST Chris Murphy wrote:
>  > We'll just have to see if there's an easy fix for the util-linux
>  > commit that broke this, which is kinda what I'm expecting. But it
>  > might be reasonable to have one specific optical media only image,
>  > perhaps Everything ISO. And then simplify the other images.
>
>  That would needlessly make it more complex than necessary to install from
>  optical media. 
What? There are only two images that are release blocking for optical
media right now.

Everything/x86_64/iso/Fedora-Everything-netinst-x86_64-_RELEASE_MILESTONE_.iso
Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-_RELEASE_MILESTONE_.iso
https://fedoraproject.org/wiki/Releases/31/ReleaseBlocking

I'm suggesting one instead of zero. Whatever image you're saying you
must have is already non-blocking so I don't even understand what
you're complaining about now.

-- 
Chris Murphy

[John M. Harris Jr]

On Friday, December 13, 2019 12:53:57 PM MST Chris Murphy wrote:
>  On Fri, Dec 13, 2019 at 10:24 AM John M. Harris Jr
> <johnmh(a)splentity.com&gt;
>  wrote:
>  >
>  >
>  > On Thursday, December 12, 2019 10:52:15 PM MST Chris Murphy wrote:
>  > 
>  > > We'll just have to see if there's an easy fix for the util-linux
>  > > commit that broke this, which is kinda what I'm expecting. But it
>  > > might be reasonable to have one specific optical media only image,
>  > > perhaps Everything ISO. And then simplify the other images.
>  >
>  >
>  >
>  > That would needlessly make it more complex than necessary to install from
>  > optical media.
>  
>  
>  What? There are only two images that are release blocking for optical
>  media right now.
>  
>  Everything/x86_64/iso/Fedora-Everything-netinst-x86_64-_RELEASE_MILESTONE_.i
>  so
>  Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-_RELEASE_MILESTONE_.i
>  so https://fedoraproject.org/wiki/Releases/31/ReleaseBlocking
>  
>  I'm suggesting one instead of zero. Whatever image you're saying you
>  must have is already non-blocking so I don't even understand what
>  you're complaining about now. 
This isn't something that *I* personally need. The only ISO image I personally 
need is the KDE Spin ISO, so you'd be correct. For end-users, there's no need 
for the complexity of the Everything image to be present, however. If the end 
user wants to install the GNOME Spin, they shouldn't have to jump through 
hoops and know what they're picking.

-- 
John M. Harris, Jr.
Splentity

[Mike Pinkerton]

On 13 Dec 2019, at 15:03, John M. Harris Jr wrote:

>  On Friday, December 13, 2019 12:53:57 PM MST Chris Murphy wrote:
> >
> > What? There are only two images that are release blocking for optical
> > media right now.
> >
> > Everything/x86_64/iso/Fedora-Everything-netinst-x86_64- 
> > _RELEASE_MILESTONE_.i
> > so
> > Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64- 
> > _RELEASE_MILESTONE_.i
> > so https://fedoraproject.org/wiki/Releases/31/ReleaseBlocking
> >
> > I'm suggesting one instead of zero. Whatever image you're saying you
> > must have is already non-blocking so I don't even understand what
> > you're complaining about now.
>
>  This isn't something that *I* personally need. The only ISO image I  
>  personally
>  need is the KDE Spin ISO, so you'd be correct. For end-users,  
>  there's no need
>  for the complexity of the Everything image to be present, however.  
>  If the end
>  user wants to install the GNOME Spin, they shouldn't have to jump  
>  through
>  hoops and know what they're picking. 
I would say that the Everything netinstall image is more useful than  
the Workstation Live image:

*  netinstall is smaller
*  netinstall can be used to install servers
*  netinstall with updates repo enabled yields current system without  
doing the almost inevitable post-install (from non-netinstall image)  
update

-- 
Mike

[stan]

On Fri, 13 Dec 2019 15:34:29 -0500
Mike Pinkerton <pselists(a)mindspring.com&gt; wrote:

>  I would say that the Everything netinstall image is more useful than 
>
>  the Workstation Live image:
>  
>  *  netinstall is smaller
>  *  netinstall can be used to install servers
>  *  netinstall with updates repo enabled yields current system without
>  doing the almost inevitable post-install (from non-netinstall image)  
>  update 
+1

[John M. Harris Jr]

On Friday, December 13, 2019 1:34:29 PM MST Mike Pinkerton wrote:
>  On 13 Dec 2019, at 15:03, John M. Harris Jr wrote:
>  
>  
>  > On Friday, December 13, 2019 12:53:57 PM MST Chris Murphy wrote:
>  > 
>  >>
>  >>
>  >> What? There are only two images that are release blocking for optical
>  >> media right now.
>  >>
>  >>
>  >>
>  >> Everything/x86_64/iso/Fedora-Everything-netinst-x86_64- 
>  >> _RELEASE_MILESTONE_.i
>  >> so
>  >> Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64- 
>  >> _RELEASE_MILESTONE_.i
>  >> so https://fedoraproject.org/wiki/Releases/31/ReleaseBlocking
>  >>
>  >>
>  >>
>  >> I'm suggesting one instead of zero. Whatever image you're saying you
>  >> must have is already non-blocking so I don't even understand what
>  >> you're complaining about now.
>  >
>  >
>  >
>  > This isn't something that *I* personally need. The only ISO image I  
>  > personally
>  > need is the KDE Spin ISO, so you'd be correct. For end-users,  
>  > there's no need
>  > for the complexity of the Everything image to be present, however.  
>  > If the end
>  > user wants to install the GNOME Spin, they shouldn't have to jump  
>  > through
>  > hoops and know what they're picking.
>  
>  
>  I would say that the Everything netinstall image is more useful than  
>  the Workstation Live image:
>  
>  *  netinstall is smaller
>  *  netinstall can be used to install servers
>  *  netinstall with updates repo enabled yields current system without  
>  doing the almost inevitable post-install (from non-netinstall image)  
>  update 
That'd be great experience for users that already know what they want. and 
have a NIC which is supported in mainline. It's also not an option for users 
installing in airgapped environments, users who don't have internet access or 
have bad internet service, among other common issues. It would NOT be a good 
experience for a user to grab a GNOME or KDE Spin DVD, attempt to boot, and 
not be able to boot it.

-- 
John M. Harris, Jr.
Splentity

[Nico Kadel-Garcia]

On Sat, Dec 14, 2019 at 1:25 AM John M. Harris Jr <johnmh(a)splentity.com&gt; wrote:
>  On Friday, December 13, 2019 1:34:29 PM MST Mike Pinkerton wrote:
>  > On 13 Dec 2019, at 15:03, John M. Harris Jr wrote:
>  >
>  >
>  > > On Friday, December 13, 2019 12:53:57 PM MST Chris Murphy wrote:
>  > >
>  > >>
>  > >>
>  > >> What? There are only two images that are release blocking for optical
>  > >> media right now.
>  > >>
>  > >>
>  > >>
>  > >> Everything/x86_64/iso/Fedora-Everything-netinst-x86_64-
>  > >> _RELEASE_MILESTONE_.i
>  > >> so
>  > >> Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-
>  > >> _RELEASE_MILESTONE_.i
>  > >> so https://fedoraproject.org/wiki/Releases/31/ReleaseBlocking
>  > >>
>  > >>
>  > >>
>  > >> I'm suggesting one instead of zero. Whatever image you're saying
> you
>  > >> must have is already non-blocking so I don't even understand what
>  > >> you're complaining about now.
>  > >
>  > >
>  > >
>  > > This isn't something that *I* personally need. The only ISO image I
>  > > personally
>  > > need is the KDE Spin ISO, so you'd be correct. For end-users,
>  > > there's no need
>  > > for the complexity of the Everything image to be present, however.
>  > > If the end
>  > > user wants to install the GNOME Spin, they shouldn't have to jump
>  > > through
>  > > hoops and know what they're picking.
>  >
>  >
>  > I would say that the Everything netinstall image is more useful than
>  > the Workstation Live image:
>  >
>  > *  netinstall is smaller
>  > *  netinstall can be used to install servers
>  > *  netinstall with updates repo enabled yields current system without
>  > doing the almost inevitable post-install (from non-netinstall image)
>  > update
>
>  That'd be great experience for users that already know what they want. and
>  have a NIC which is supported in mainline. It's also not an option for users
>  installing in airgapped environments, users who don't have internet access or
>  have bad internet service, among other common issues. It would NOT be a good
>  experience for a user to grab a GNOME or KDE Spin DVD, attempt to boot, and
>  not be able to boot it.
>
>  --
>  John M. Harris, Jr.
>  Splentity 
Part of my approach for airgapped environments, and environments I
want to do installs and updates from my local network for,  has been
to bring external an external medium, such as a USB drive, with a full
mirror of all of that fedora release's current upstream mirror. and
mount *that*. It's currently about 150 GB for the entire Fedora 31
release. The approach has also been very handy when setting up
clusters or when the installer lacks network drivers until after the
kernel update, and I don't want to spend cycles building a new
bootable image.

I'll also admit that since 2000, I've building tarballs of OS images
much as "mock" builds cached OS images and using them on a network
kickstart or installer CD image to ignore most of anaconda, partition
the disk image with anaconda's '%pre" scripting, and blow the OS image
onto the disk. It's *much, much, much faster* than negotiating the
graphical anaconda screens and selections and it provides *much* more
flexibility for disk partitioning than sitting down working through
the  anaconda disk paritioning or software selection GUI provides.
The approach uses anaconda's scripting tools to provide very scalable
deployments, I once used it for 13,000 deployed systems in one month,
including negotiating which of the network ports were eth0 and which
eth1for consistent "eth1 is on top!!!!" for the poor beggars wiring up
the machines.

[Kevin Kofler]

Chris Murphy wrote:
>  What? There are only two images that are release blocking for
> optical
>  media right now.
>  
>  Everything/x86_64/iso/Fedora-Everything-netinst-x86_64- 
_RELEASE_MILESTONE_.iso
>  Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-
_RELEASE_MILESTONE_.iso
>  https://fedoraproject.org/wiki/Releases/31/ReleaseBlocking 
Who decided this, when?

To my knowledge, it was agreed that the KDE x86_64 Live should be release 
blocking. Nowhere was it agreed back then, nor ever since, that this should 
only apply to some types of physical (or virtual) media and not others. I 
hereby request that the KDE Live x86_64 be made release-blocking for optical 
media again, unless explicitly agreed otherwise with the KDE SIG.

        Kevin Kofler

[Adam Williamson]

On Sat, 2019-12-14 at 02:18 +0100, Kevin Kofler wrote:
>  Chris Murphy wrote:
>  > What? There are only two images that are release blocking for optical
>  > media right now.
>  > 
>  > Everything/x86_64/iso/Fedora-Everything-netinst-x86_64-
>  _RELEASE_MILESTONE_.iso
>  > Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-
>  _RELEASE_MILESTONE_.iso
>  > https://fedoraproject.org/wiki/Releases/31/ReleaseBlocking
>  
>  Who decided this, when? 
It was decided on this list and test@ , in January 2017:

https://lists.fedoraproject.org/archives/list/[e-mail].o...
https://lists.fedoraproject.org/archives/list/[e-mail]...
https://fedoraproject.org/w/index.php?title=Releases/26/ReleaseBlocking&a...

Note, this isn't exactly a case of 'Workstation is more important than
KDE'. Rather, the idea was that we can be more efficient in testing by
only testing *one* live image, because all the live images are built
exactly the same way, so if one boots there's really absolutely no
reason all the others shouldn't boot too. Similarly for traditional
installer images. So, we picked the Everything netinst as the
'representative' for traditional installer images, and the Workstation
live as the 'representative' for live images; the idea is that if we
just test those two, it 99.99999% proves all the others will also boot.

If this proposal is accepted, of course, the question becomes moot; but
if it isn't, we can look at tweaking how this is explained in the wiki
and test matrix, because this element is not really clear as things
stand (and I'd forgotten it and had to re-read the threads to refresh
my memory).
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[David Cantrell]

On Thu, Dec 12, 2019 at 07:59:54PM -0600, Richard Shaw wrote:
> Ok, obvious question first... Has this caused any problems? When was
> the
> last time this failed?
>
> The latter part is for selfish reasons... I still have one (decent)
> computer with primitive EFI BIOS that will only boot UEFI from optical
> media, not from USB (weird, I know). 
I also want optical media for some systems, but the testing and verification
cycle for that for each release takes a lot of effort.  It's easier to
disconnect that from the release process and have it come along after the fact
once the churn slows down and the rest of the release is taken care of.

In my experience, there have *always* been boot media problems at the end of
every release cycle.  Some are solvable, others are not.

-- 
David Cantrell <dcantrell(a)redhat.com&gt;
Red Hat, Inc. | Boston, MA | EST5EDT

[Kevin Kofler]

Ben Cotton wrote:
>  Proposal to make all Fedora optical media non-blocking. This means
>  we'd stop blocking on bugs found during the installation of Fedora
>  from optical media (like CDs and DVDs). This doesn't mean that
>  installation from optical media would stop working, just that the
>  Fedora Release wouldn't be blocked on any issues that can pop up in
>  Fedora installation using this method. Installation from USB devices
>  will remain blocking. 
I am against this Change. This is clearly a special case of Fedora not being 
installable at all on a significant subset of hardware. I do not think it is 
acceptable to ship it that way.

        Kevin Kofler

[Frantisek Zatloukal]

On Fri, Dec 13, 2019 at 9:28 AM Vitaly Zaitsev via devel <
devel(a)lists.fedoraproject.org&gt; wrote:

>  On 12.12.2019 21:37, Ben Cotton wrote:
>  > Proposal to make all Fedora optical media non-blocking. This means
>  > we'd stop blocking on bugs found during the installation of Fedora
>  > from optical media (like CDs and DVDs). This doesn't mean that
>  > installation from optical media would stop working, just that the
>  > Fedora Release wouldn't be blocked on any issues that can pop up in
>  > Fedora installation using this method. Installation from USB devices
>  > will remain blocking.
>
>  I'm strongly against this change. There are still lots of working
>  hardware that does not support booting from USB in UEFI mode (first wave
>  of hardware with UEFI BIOS).
>
>  Fedora should be installable on all supported hardware.
>
>  
On Fri, Dec 13, 2019 at 3:19 AM Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote:

>  Ben Cotton wrote:
>  > Proposal to make all Fedora optical media non-blocking. This means
>  > we'd stop blocking on bugs found during the installation of Fedora
>  > from optical media (like CDs and DVDs). This doesn't mean that
>  > installation from optical media would stop working, just that the
>  > Fedora Release wouldn't be blocked on any issues that can pop up in
>  > Fedora installation using this method. Installation from USB devices
>  > will remain blocking.
>
>  I am against this Change. This is clearly a special case of Fedora not
>  being
>  installable at all on a significant subset of hardware. I do not think it
>  is
>  acceptable to ship it that way.
>
>  This change is not aimed to make Fedora non-installable via CD/DVD. As 
it's
written in the proposal, *"This doesn't mean that installation from
optical media would stop working, just that the Fedora Release wouldn't be
blocked on any issues that can pop up in Fedora installation using this
method. " *

Also, if you care about Fedora being installable from CD or DVD, you might
want to help with testing. Bugs will be handled like any other bugs found
in Fedora. No one apart from Fedora QE Team members filled F31 Final
Validation Testing Matrix for optical media installation [0][1][2].

As for HW that does not support USB boot, there will always be some HW
without USB boot support caused probably by firmware bugs. However, the
vast majority of HW sold in last decade should support USB boot just fine.
Even desktop I had in 2004 supported USB boot...

This proposal would allow QE to focus more on areas which are exposed to
the majority of users instead of having to spend limited time and resources
by burning CDs and testing them just to make sure it works for fraction of
user base. I don't expect to suddenly have F32 released with broken boot
from optical media.

[0]
https://fedoraproject.org/wiki/Test_Results:Fedora_31_RC_1.3_Installation...
[1]
https://fedoraproject.org/wiki/Test_Results:Fedora_31_RC_1.8_Installation...
[2]
https://fedoraproject.org/wiki/Test_Results:Fedora_31_RC_1.9_Installation...

[John M. Harris Jr]

On Friday, December 13, 2019 2:00:41 AM MST Frantisek Zatloukal wrote:
[snip]
>  I don't expect to suddenly have F32 released with broken boot
> from
>  optical media. 
If we don't want that to occur, optical media needs to remain a release 
blocker.

-- 
John M. Harris, Jr.
Splentity

[Simo Sorce]

On Fri, 2019-12-13 at 10:28 -0700, John M. Harris Jr wrote:
>  On Friday, December 13, 2019 2:00:41 AM MST Frantisek Zatloukal
> wrote:
>  [snip]
>  > I don't expect to suddenly have F32 released with broken boot from
>  > optical media.
>  
>  If we don't want that to occur, optical media needs to remain a release 
>  blocker. 
Are you volunteering to fix the blocker bugs?

If not it should be on those that handle boot and QA to decide.

Install from optical is not anymore release critical, that is evident.
The fact that "there are some machines that do not support USB booting"
self-explanatorily tells you it is a small minority of basically broken
hardware which should not block a whole release.

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc

[Kevin Kofler]

Simo Sorce wrote:
>  Install from optical is not anymore release critical, that is
> evident. 
To whom? All the VM testing I do is always with -cdrom foo.iso, so it would 
break my VM testing completely. And there is also real hardware that it 
would break (and there, you cannot work around it by just changing some 
command-line flags).

>  The fact that "there are some machines that do not support USB
> booting"
>  self-explanatorily tells you it is a small minority of basically broken
>  hardware which should not block a whole release. 
Since this cannot be fixed in an update (at least as long as Respins are 
still considered unofficial), it should.

        Kevin Kofler

[Adam Williamson]

On Sat, 2019-12-14 at 02:30 +0100, Kevin Kofler wrote:
>  Simo Sorce wrote:
>  > Install from optical is not anymore release critical, that is evident.
>  
>  To whom? All the VM testing I do is always with -cdrom foo.iso, so it would 
>  break my VM testing completely. And there is also real hardware that it 
>  would break (and there, you cannot work around it by just changing some 
>  command-line flags). 
So, the virtual vs. real thing here is actually a bit unclear at
present. The criterion we're proposing dropping specifically talks
about real, physical optical media:

"Release-blocking live and dedicated installer images must boot when
written to optical media of an appropriate size"...

But, if you look at the Basic and Beta criteria, neither of those
actually talks about virtual media at all: they just talk about "USB
sticks" (which also implies real physical USB stick, to me at least,
and I wrote them :>).

The virtualization criterion doesn't get into the nitty gritty of
virtual media types, it just says "The release must install and boot
successfully as a virtual guest in a situation where the virtual host
is running the current stable Fedora release."

So if we somehow got a case where a release-blocking ISO booted as a
virtual USB stick but not as a virtual DVD, that would actually be a
fairly difficult case to call as a blocker, both as the criteria stand
right now and if this Change was accepted. Essentially it would be a
conditional violation of the virtualization criterion: it'd be broken
*if you configure your VM to use the image as a virtual optical disc*,
but not if you configure your VM to use the image as a virtual USB
stick. As a conditional violation it'd be a subjective decision by
whoever showed up to blocker review, and I wouldn't want to guess which
way that decision would go, to be honest. I'd probably vote +1, but I
dunno which way others would vote.

So, while we're considering this Change proposal, we might actually
also want to think about clarifying the virtual media requirements a
bit in the criteria at the same time...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Simo Sorce]

On Fri, 2019-12-13 at 03:17 +0100, Kevin Kofler wrote:
>  Ben Cotton wrote:
>  > Proposal to make all Fedora optical media non-blocking. This means
>  > we'd stop blocking on bugs found during the installation of Fedora
>  > from optical media (like CDs and DVDs). This doesn't mean that
>  > installation from optical media would stop working, just that the
>  > Fedora Release wouldn't be blocked on any issues that can pop up in
>  > Fedora installation using this method. Installation from USB devices
>  > will remain blocking.
>  
>  I am against this Change. This is clearly a special case of Fedora not being 
>  installable at all on a significant subset of hardware. I do not think it is 
>  acceptable to ship it that way. 
Significant how?
I haven't seen optical media on new devices for many years now ...
And *all* old devices also have USB outlets, so it is unclear how this
would make Fedora not installable.
Any machine so old to have optical media but not USB is probably
already not working due to other factors like being i686 only).

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc

[John M. Harris Jr]

On Friday, December 13, 2019 12:16:12 PM MST Simo Sorce wrote:
>  And *all* old devices also have USB outlets, so it is unclear how
> this
>  would make Fedora not installable.
>  Any machine so old to have optical media but not USB is probably
>  already not working due to other factors like being i686 only). 
Simply having USB ports physically present is not sufficient to boot from USB. 
It is not supported by a surprisingly large number of systems, especially on 
systems from OEMs that roll their own UEFI firmware or first/second generation 
UEFI systems. Additionally, many mainline servers, even today, still do not 
support boot from USB, and many that do support booting from USB don't support 
booting from USB images over their remote management interfaces, only optical 
images to emulate an optical disk.

-- 
John M. Harris, Jr.
Splentity

[Vitaly Zaitsev]

On 12.12.2019 21:37, Ben Cotton wrote:
>  Proposal to make all Fedora optical media non-blocking. This means
>  we'd stop blocking on bugs found during the installation of Fedora
>  from optical media (like CDs and DVDs). This doesn't mean that
>  installation from optical media would stop working, just that the
>  Fedora Release wouldn't be blocked on any issues that can pop up in
>  Fedora installation using this method. Installation from USB devices
>  will remain blocking. 
I'm strongly against this change. There are still lots of working
hardware that does not support booting from USB in UEFI mode (first wave
of hardware with UEFI BIOS).

Fedora should be installable on all supported hardware.

-- 
Sincerely,
  Vitaly Zaitsev (vitaly(a)easycoding.org)

[Miro Hrončok]

On 12. 12. 19 21:37, Ben Cotton wrote:
>  https://fedoraproject.org/wiki/Changes/Drop_Optical_Media_Criterion
>  
>  = Drop Optical Media Release Criterion =
>  
>  == Summary ==
>  Proposal to make all Fedora optical media non-blocking. This means
>  we'd stop blocking on bugs found during the installation of Fedora
>  from optical media (like CDs and DVDs). This doesn't mean that
>  installation from optical media would stop working, just that the
>  Fedora Release wouldn't be blocked on any issues that can pop up in
>  Fedora installation using this method. Installation from USB devices
>  will remain blocking. 
Juts a random idea, not very thought-out:

Could we keep optical media bugs reported by users as blocking, but not require 
it during validation testing?


aka: Fedora QE would no longer have to verify optical media works.
but: If a tester finds an optical media  bug, it is still blocking.

That would still have 2 of the 3 listed benefits. The remaining benefit is 
arguable (is optical media a corner case? there are no corners on DVD).

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[James Cassell]

On Fri, Dec 13, 2019, at 6:02 AM, Miro Hrončok wrote:
>  On 12. 12. 19 21:37, Ben Cotton wrote:
>  > https://fedoraproject.org/wiki/Changes/Drop_Optical_Media_Criterion
>  > 
>  > = Drop Optical Media Release Criterion =
>  > 
>  > == Summary ==
>  > Proposal to make all Fedora optical media non-blocking. This means
>  > we'd stop blocking on bugs found during the installation of Fedora
>  > from optical media (like CDs and DVDs). This doesn't mean that
>  > installation from optical media would stop working, just that the
>  > Fedora Release wouldn't be blocked on any issues that can pop up in
>  > Fedora installation using this method. Installation from USB devices
>  > will remain blocking.
>  
>  Juts a random idea, not very thought-out:
>  
>  Could we keep optical media bugs reported by users as blocking, but not require 
>  it during validation testing?
>   
I'm against the change as- is, but I could support this. I use optical media
extensively for reasons beyond my control. It's also useful for virtual CD on hardware
via IPMI/iDRAC, depending on the vendor.

I'll try to get back to help fill out the test matrix as I had done years ago.

>  
>  aka: Fedora QE would no longer have to verify optical media works.
>  but: If a tester finds an optical media  bug, it is still blocking.
>   
+1

V/r,
James Cassell

[Chris Murphy]

On Fri, Dec 13, 2019 at 4:03 AM Miro Hrončok <mhroncok(a)redhat.com&gt; wrote:
>  On 12. 12. 19 21:37, Ben Cotton wrote:
>  > https://fedoraproject.org/wiki/Changes/Drop_Optical_Media_Criterion
>  >
>  > = Drop Optical Media Release Criterion =
>  >
>  > == Summary ==
>  > Proposal to make all Fedora optical media non-blocking. This means
>  > we'd stop blocking on bugs found during the installation of Fedora
>  > from optical media (like CDs and DVDs). This doesn't mean that
>  > installation from optical media would stop working, just that the
>  > Fedora Release wouldn't be blocked on any issues that can pop up in
>  > Fedora installation using this method. Installation from USB devices
>  > will remain blocking.
>
>  Juts a random idea, not very thought-out:
>
>  Could we keep optical media bugs reported by users as blocking, but not require
>  it during validation testing?
>
>
>  aka: Fedora QE would no longer have to verify optical media works.
>  but: If a tester finds an optical media  bug, it is still blocking.
>
>  That would still have 2 of the 3 listed benefits. The remaining benefit is
>  arguable (is optical media a corner case? there are no corners on DVD). 
I think it could be reasonable for Fedora QA to only have automated
testing, where VM's in openQA use the qemu DVD/CD device, and still
block on release if any of those tests fail. But not require Fedora QA
to actually buy and burn optical media and do physical tests.

Of course it's possible the qemu device doesn't discover bugs that
would affect real optical devices, and therefore users who claim they
need this functionality really should be testing it, not expecting
others to do this. And I also think the late blockers rule should
apply to it, so testing needs to be done early not only at the last
few days before final release.


-- 
Chris Murphy

[Adam Williamson]

On Fri, 2019-12-13 at 12:02 +0100, Miro Hrončok wrote:
>  On 12. 12. 19 21:37, Ben Cotton wrote:
>  > https://fedoraproject.org/wiki/Changes/Drop_Optical_Media_Criterion
>  > 
>  > = Drop Optical Media Release Criterion =
>  > 
>  > == Summary ==
>  > Proposal to make all Fedora optical media non-blocking. This means
>  > we'd stop blocking on bugs found during the installation of Fedora
>  > from optical media (like CDs and DVDs). This doesn't mean that
>  > installation from optical media would stop working, just that the
>  > Fedora Release wouldn't be blocked on any issues that can pop up in
>  > Fedora installation using this method. Installation from USB devices
>  > will remain blocking.
>  
>  Juts a random idea, not very thought-out:
>  
>  Could we keep optical media bugs reported by users as blocking, but not require 
>  it during validation testing?
>  
>  
>  aka: Fedora QE would no longer have to verify optical media works.
>  but: If a tester finds an optical media  bug, it is still blocking.
>  
>  That would still have 2 of the 3 listed benefits. The remaining benefit is 
>  arguable (is optical media a corner case? there are no corners on DVD). 
Personally speaking I don't really *like* this fudge, but yes, we *can*
do it. We actually have one fudge of precisely this kind in the
criteria right now, so there is a clear precedent. It's to do with
Cockpit browser support:

https://fedoraproject.org/wiki/Fedora_32_Final_Release_Criteria#Cockpit_m...

"Manual testing will occur on the Firefox/Fedora platform. It will not
be performed on the Chrome/Fedora platform nor any of the Windows / OSX
platforms mentioned above, but if issues in code related to Fedora /
Cockpit (and not third-party software such as the third-party browsers)
in meeting the functional criteria are reported against those
platforms, they may block the release."
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Justin W. Flory]

Hi all,

I was surprised to see this Change be proposed without engagement with the Fedora
Mindshare Committee or reaching out to the advocacy / user communities for more feedback.
There are a lot of people this Change could impact and I am concerned many of those voices
are not represented in this discussion or on this list.

Is there any data or supporting evidence to support back this Change? Other than private
RH BZ customer tickets? I am really curious to know the "why" behind this Change
other than eliminating an admittedly tedious task for the QA team to perform. I am
thinking about this from two points-of-view:


(1) This change affects people differently in different regions of the world

The Fedora community has large user and contributor communities all over the world.
Historically, our Ambassadors/Advocates relied on DVD media in these regions to install
Fedora and promote it at events, because there is not always reliable, consistent Internet
connection in parts of these regions. Additionally, the hardware that exists in these
regions is often previous-generation hardware that does not mirror the same hardware
advances in the West.

Without more data on DVD media usage to support this Change, I am concerned of the impact
of this Change on Fedora user and advocacy communities that may still rely on this as a
vital deliverable to support their community work in promoting Fedora globally.


(2) USB media were always turned down in the Fedora budget requests for
Ambassadors/Advocates throughout the last decade.

In the Ambassador/Advocate community, there are volunteers from North America / Europe who
advocated for Fedora USB keys for years. Throughout my five or six years in Fedora now,
these requests from the community were always turned down because of cost. If memory serve
me correctly, the cost of mass-producing USB media for our community was $100s of USD, if
not $1000s, more.

So, the other consequence of this Change could be that we leave a lot of people doing
valuable community work behind, because DVD media is no longer release blocking and Fedora
community advocates can't get USB keys funded. (Except, somehow, Fedora-branded USB
keys were acquired for past FOSDEM events, I don't remember seeing this decision work
its way through the community though.)

From a non-engineering / Fedora community perspective, I am strongly -1 to this proposal
without more data to support this. I think a better approach to inform this decision is to
collaborate with the Mindshare Committee on collecting feedback from the wider community
about this Change. Holding it here on this mailing list is not enough because only the
most active, most passionate people are likely to join this discussion.


>  Juts a random idea, not very thought-out:
>  
>  Could we keep optical media bugs reported by users as blocking, but not require 
>  it during validation testing?
>  
>  
>  aka: Fedora QE would no longer have to verify optical media works.
>  but: If a tester finds an optical media  bug, it is still blocking.
>  
>  That would still have 2 of the 3 listed benefits. The remaining benefit is 
>  arguable (is optical media a corner case? there are no corners on DVD). 
For what it's worth, I like Miro's idea a lot but also haven't thought about
it extensively. I think this could prioritize these issues as release-blocking when we
don't have enough data to understand the impact of this Change, but it also saves a
lot of time and effort on the QA team for shipping releases to focus on other things.
Another piece of feedback I'd be interested to know is how often serious issues do
come up when testing optical media, or if the issue is that it is just a lot of manual
work that is hard to do.

Some of my 2¢.

[Nico Kadel-Garcia]

On Sat, Dec 14, 2019 at 9:26 AM Justin W. Flory <jflory7(a)gmail.com&gt; wrote:

>  For what it's worth, I like Miro's idea a lot but also
> haven't thought about it extensively. I think this could prioritize these issues as
> release-blocking when we don't have enough data to understand the impact of this
> Change, but it also saves a lot of time and effort on the QA team for shipping releases to
> focus on other things. Another piece of feedback I'd be interested to know is how
> often serious issues do come up when testing optical media, or if the issue is that it is
> just a lot of manual work that is hard to do.
>
>  Some of my 2¢. 
Isn't the primary optical media testing done these days by mounting an
iso image attached to a virtual machine? I'd not even bother burning
media these days until it passed this test, due to the need for
hands-on media management. And it's certainly one of the use caes for
virtual media and iso images. I'm not suggesting that physical media
not be tested, but isn't all the media testing first done with a
virtual OS and virtual media? In which case, the virtual image testing
is pretty much happening anyway.

[Adam Williamson]

On Sat, 2019-12-14 at 09:37 -0500, Nico Kadel-Garcia wrote:
>  On Sat, Dec 14, 2019 at 9:26 AM Justin W. Flory
> <jflory7(a)gmail.com&gt; wrote:
>  
>  > For what it's worth, I like Miro's idea a lot but also haven't
>  > thought about it extensively. I think this could prioritize these
>  > issues as release-blocking when we don't have enough data to
>  > understand the impact of this Change, but it also saves a lot of
>  > time and effort on the QA team for shipping releases to focus on
>  > other things. Another piece of feedback I'd be interested to know
>  > is how often serious issues do come up when testing optical media,
>  > or if the issue is that it is just a lot of manual work that is
>  > hard to do.
>  > 
>  > Some of my 2¢.
>  
>  Isn't the primary optical media testing done these days by mounting an
>  iso image attached to a virtual machine? I'd not even bother burning
>  media these days until it passed this test, due to the need for
>  hands-on media management. And it's certainly one of the use caes for
>  virtual media and iso images. I'm not suggesting that physical media
>  not be tested, but isn't all the media testing first done with a
>  virtual OS and virtual media? In which case, the virtual image testing
>  is pretty much happening anyway. 
Yes, but the point of this proposal is that we are still required to
test actual physical media. Booting from a virtual optical disc is
tested automatically several dozen times with each nightly compose.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Miro Hrončok]

On 14. 12. 19 15:25, Justin W. Flory wrote:
>  I was surprised to see this Change be proposed without engagement
> with the Fedora Mindshare Committee or reaching out to the advocacy / user communities for
> more feedback.  
Just a note without replying to your other specific concerns.

The devel list is the first place where developers gather feedback. The idea to 
reach a committee (whether FESCo or Mindshare) before reaching to devel is hence 
entirely wrong in my opinion. Committees should rubber stamp community 
decisions, not drive them.

As for users communities, yes, that is a good idea. However, so is first 
discussing this within the engineering contributors community and only once 
there is a consensus, involve advocacy / user communities for more feedback.

Hence, I disagree with what you say - discussing this on the devel list first is 
the best thing to do IMHO.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[John M. Harris Jr]

On Saturday, December 14, 2019 7:39:15 AM MST Miro Hrončok wrote:
>  On 14. 12. 19 15:25, Justin W. Flory wrote:
>  
>  > I was surprised to see this Change be proposed without engagement with the
>  > Fedora Mindshare Committee or reaching out to the advocacy / user
>  > communities for more feedback. 
>  
>  Just a note without replying to your other specific concerns.
>  
>  The devel list is the first place where developers gather feedback. The idea
>  to  reach a committee (whether FESCo or Mindshare) before reaching to
>  devel is hence entirely wrong in my opinion. Committees should rubber stamp
>  community decisions, not drive them. 
Agreed, though I wouldn't say "rubber stamp", so much as
"influence".

-- 
John M. Harris, Jr.
Splentity

[Adam Williamson]

On Sat, 2019-12-14 at 14:25 +0000, Justin W. Flory wrote:
>  Hi all,
>  
>  I was surprised to see this Change be proposed without engagement
>  with the Fedora Mindshare Committee or reaching out to the advocacy /
>  user communities for more feedback. There are a lot of people this
>  Change could impact and I am concerned many of those voices are not
>  represented in this discussion or on this list.
>  
>  Is there any data or supporting evidence to support back this Change?
>  Other than private RH BZ customer tickets? I am really curious to
>  know the "why" behind this Change other than eliminating an
>  admittedly tedious task for the QA team to perform. I am thinking
>  about this from two points-of-view: 
There is no "why" behind this Change "other than eliminating an
admittedly tedious task for the QA team". That's the whole thing. There
aren't any "private RH BZ customer tickets". Why would RH customers
care about whether or not Fedora blocks on physical optical media
booting?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Adam Williamson]

On Sat, 2019-12-14 at 14:25 +0000, Justin W. Flory wrote:
>  (2) USB media were always turned down in the Fedora budget requests
>  for Ambassadors/Advocates throughout the last decade.
>  
>  In the Ambassador/Advocate community, there are volunteers from North
>  America / Europe who advocated for Fedora USB keys for years.
>  Throughout my five or six years in Fedora now, these requests from
>  the community were always turned down because of cost. If memory
>  serve me correctly, the cost of mass-producing USB media for our
>  community was $100s of USD, if not $1000s, more.
>  
>  So, the other consequence of this Change could be that we leave a lot
>  of people doing valuable community work behind, because DVD media is
>  no longer release blocking and Fedora community advocates can't get
>  USB keys funded. (Except, somehow, Fedora-branded USB keys were
>  acquired for past FOSDEM events, I don't remember seeing this
>  decision work its way through the community though.) 
If there are all these thousands of people out there who care deeply
about the optical media...wouldn't it be nice if some of them turned up
and helped run the tests once in a while?

>  > Juts a random idea, not very thought-out:
>  > Could we keep optical media bugs reported by users as blocking, but not require 
>  > it during validation testing?
>  > aka: Fedora QE would no longer have to verify optical media works.
>  > but: If a tester finds an optical media  bug, it is still blocking.
>  > That would still have 2 of the 3 listed benefits. The remaining benefit is 
>  > arguable (is optical media a corner case? there are no corners on DVD).
>  
>  For what it's worth, I like Miro's idea a lot but also haven't
>  thought about it extensively. I think this could prioritize these
>  issues as release-blocking when we don't have enough data to
>  understand the impact of this Change, but it also saves a lot of time
>  and effort on the QA team for shipping releases to focus on other
>  things. Another piece of feedback I'd be interested to know is how
>  often serious issues do come up when testing optical media, or if the
>  issue is that it is just a lot of manual work that is hard to do. 
Very very rarely. As Chris Murphy wrote, by pure coincidence one showed
up the day before yesterday (to be clear, it has nothing at all to do
with this Change proposal, the proposers of the Change were not aware
of that bug until well after the Change was submitted). Before that the
last time I can find, by searching my Bugzilla mail box for relevant
words at least, is 2015:

https://bugzilla.redhat.com/show_bug.cgi?id=1250440

the last time we had a *fatal* issue that I can find is 2014:

https://bugzilla.redhat.com/show_bug.cgi?id=1148087

Note, the testing isn't *hard* to do, really, it's just tedious and
time consuming. Not just the act of running the test (though that does
take quite a while, between the burning process and the boot, media
check and install itself), but the fact that it means we need to ensure
we have at least a couple of people who still have access to a DVD
burner and blank media.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[John M. Harris Jr]

On Saturday, December 14, 2019 9:26:12 AM MST Adam Williamson wrote:
>  Note, the testing isn't *hard* to do, really, it's just
> tedious and
>  time consuming. Not just the act of running the test (though that does
>  take quite a while, between the burning process and the boot, media
>  check and install itself), but the fact that it means we need to ensure
>  we have at least a couple of people who still have access to a DVD
>  burner and blank media. 
What is the process for this now? i.e. is this only tested once virtual cd 
image tests have been completed?

As for having a DVD burner, that's been a standard option on workstations 
since ~2005.

-- 
John M. Harris, Jr.
Splentity

[Adam Williamson]

On Sat, 2019-12-14 at 10:28 -0700, John M. Harris Jr wrote:
>  On Saturday, December 14, 2019 9:26:12 AM MST Adam Williamson wrote:
>  > Note, the testing isn't *hard* to do, really, it's just tedious and
>  > time consuming. Not just the act of running the test (though that does
>  > take quite a while, between the burning process and the boot, media
>  > check and install itself), but the fact that it means we need to ensure
>  > we have at least a couple of people who still have access to a DVD
>  > burner and blank media.
>  
>  What is the process for this now? i.e. is this only tested once virtual cd 
>  image tests have been completed? 
Yes, but I don't see the *relevance* of that. You keep mentioning it,
but I don't see what it has to do with the Change at all. The physical
testing takes the same time either way.

It would be nearly impossible to do the physical testing before virtual
tests have run, because the virtual tests are automated, openQA runs
them as soon as the compose completes. If virtual optical media boot is
broken we find out approximately 10 minutes after the compose completes
(5 minutes for the tests to be scheduled and the Everything network
install ISO to be downloaded, 5 minutes for the test to time out).

>  As for having a DVD burner, that's been a standard option on
> workstations 
>  since ~2005. 
Well...not really. It *was* a standard option in 2005. It is
increasingly becoming less standard as time goes on.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[John M. Harris Jr]

On Saturday, December 14, 2019 10:42:57 AM MST Adam Williamson wrote:
>  > What is the process for this now? i.e. is this only tested once
> virtual cd
>  >  image tests have been completed?
>  
>  
>  Yes, but I don't see the *relevance* of that. You keep mentioning it,
>  but I don't see what it has to do with the Change at all. The physical
>  testing takes the same time either way. 
To clarify, I only asked this once, because it was an obvious area to remove 
the need for physical media, if it wasn't already done. I didn't really expect 
a different answer, but didn't want to run with an assumption.

>  It would be nearly impossible to do the physical testing before
> virtual
>  tests have run, because the virtual tests are automated, openQA runs
>  them as soon as the compose completes. If virtual optical media boot is
>  broken we find out approximately 10 minutes after the compose completes
>  (5 minutes for the tests to be scheduled and the Everything network
>  install ISO to be downloaded, 5 minutes for the test to time out).
>  
>  
>  > As for having a DVD burner, that's been a standard option on workstations
>  > since ~2005.
>  
>  
>  Well...not really. It *was* a standard option in 2005. It is
>  increasingly becoming less standard as time goes on. 
I find it hard to believe that this is just something I'm experiencing, but 
here's a little anecdote. I recently ordered a set of RHEL certified 
workstations from Dell. We never mentioned that we needed a CD/DVD drive, and 
yet each system had a DVD R/W drive.

-- 
John M. Harris, Jr.
Splentity

<snip>

Hello all.
Sorry but as far as I can understand, and as stated in the proposal as
well by other people, the possibility to boot from optical media will
be not dropped.
Nobody is stating that we will prevent Fedora to boot from a DVD.

As far as I can say, if you look here: 
https://fedoraproject.org/wiki/Releases/31/ReleaseBlocking, a lot of
people should be concerned and alarmed, why not?

An example is that the day of the go/no-go meeting, Fedora will be
released even if the FXCE image doesn't work. Isn't it? And if you look
at that link, even now if the KDE spin doesn't boot from a DVD, Fedora
will be released as well.

So? What does that mean? We don't care about XFCE users? We don't care
about all other spins users? I don't thik so.

It is obvious that even if a spin is not release blocking, there will
be the same hard works in order to fix any issue with these spins
before the release date. 
In this case I think that there will be hard works to fix issues if
someone will notice some bug in the optical media boot.
It is also obvious that there should be someone committed to perform
these tests and find bugs well in advance.


Ciao,
A.

[John M. Harris Jr]

On Sunday, December 15, 2019 10:02:19 AM MST alciregi(a)gmail.com wrote:
>  Hello all.
>  Sorry but as far as I can understand, and as stated in the proposal as
>  well by other people, the possibility to boot from optical media will
>  be not dropped.
>  Nobody is stating that we will prevent Fedora to boot from a DVD. 
This is a concern because it means that it's possible to ship a release with a 
broken installer image.

>  As far as I can say, if you look here: 
>  https://fedoraproject.org/wiki/Releases/31/ReleaseBlocking, a lot of
>  people should be concerned and alarmed, why not?
>  
>  An example is that the day of the go/no-go meeting, Fedora will be
>  released even if the FXCE image doesn't work. Isn't it? And if you look
>  at that link, even now if the KDE spin doesn't boot from a DVD, Fedora
>  will be released as well.
>  
>  So? What does that mean? We don't care about XFCE users? We don't care
>  about all other spins users? I don't thik so.
>  
>  It is obvious that even if a spin is not release blocking, there will
>  be the same hard works in order to fix any issue with these spins
>  before the release date. 
>  In this case I think that there will be hard works to fix issues if
>  someone will notice some bug in the optical media boot.
>  It is also obvious that there should be someone committed to perform
>  these tests and find bugs well in advance. 
The GNOME Spin has always gotten preferential treatment, and I don't see that 
changing. That is a discussion for another thread, but it's definitely an 
issue.

-- 
John M. Harris, Jr.
Splentity

[Frantisek Zatloukal]

On Sun, Dec 15, 2019 at 6:15 PM John M. Harris Jr <johnmh(a)splentity.com&gt;
wrote:

>  On Sunday, December 15, 2019 10:02:19 AM MST alciregi(a)gmail.com
> wrote:
>  > Hello all.
>  > Sorry but as far as I can understand, and as stated in the proposal as
>  > well by other people, the possibility to boot from optical media will
>  > be not dropped.
>  > Nobody is stating that we will prevent Fedora to boot from a DVD.
>
>  This is a concern because it means that it's possible to ship a release
>  with a
>  broken installer image.
>  
No, this doesn't mean it'd be possible to ship a release with broken
installer image. Just that it wouldn't need to work from CD/DVD doesn't
make it broken.


>  The GNOME Spin has always gotten preferential treatment, and I don't see
>  that
>  changing. That is a discussion for another thread, but it's definitely an
>  issue.
>  
Similarly like others said for optical media testing, if you think it's an
issue, you're (or anybody else) more than welcome to help with validation
testing of other spins.

[John M. Harris Jr]

On Sunday, December 15, 2019 11:35:16 AM MST Frantisek Zatloukal wrote:
>  No, this doesn't mean it'd be possible to ship a release with
> broken
>  installer image. Just that it wouldn't need to work from CD/DVD doesn't
>  make it broken. 
Not working means broken.

-- 
John M. Harris, Jr.
Splentity

[Frantisek Zatloukal]

On Sun, Dec 15, 2019 at 7:52 PM John M. Harris Jr <johnmh(a)splentity.com&gt;
wrote:

>  Not working means broken.
>  
Part of this proposal is removing optical media from supported installation
methods.
From your point of view, Fedora is broken right now because, for example,
it doesn't work from USB Media created by UNetbootin most of the time.
It'll be the same, optical media will get delisted from supported
installation methods, so Fedora wouldn't be broken if it doesn't work from
installation source created using an unsupported method/media . .... Or, if
you don't agree with that, then it's already broken ;)

[John M. Harris Jr]

On Sunday, December 15, 2019 12:29:18 PM MST Frantisek Zatloukal wrote:
>  On Sun, Dec 15, 2019 at 7:52 PM John M. Harris Jr
> <johnmh(a)splentity.com&gt;
>  
>  wrote:
>  > Not working means broken.
>  
>  Part of this proposal is removing optical media from supported installation
>  methods. 
That was not brought up elsewhere in this thread. Who is considering this, and 
why? That would mean that a large portion of users would *not be able to 
install Fedora*.

>  From your point of view, Fedora is broken right now because, for
> example,
>  it doesn't work from USB Media created by UNetbootin most of the time. 
UNetbootin has never been a supported method of creating USB media.

>  It'll be the same, optical media will get delisted from
> supported
>  installation methods, so Fedora wouldn't be broken if it doesn't work from
>  installation source created using an unsupported method/media . .... Or, if
>  you don't agree with that, then it's already broken ;) 
Optical media is a supported installation method.

-- 
John M. Harris, Jr.
Splentity

[Frantisek Zatloukal]

On Sun, Dec 15, 2019 at 9:05 PM John M. Harris Jr <johnmh(a)splentity.com&gt;
wrote:

>  That was not brought up elsewhere in this thread. Who is considering
> this,
>  and
>  why? That would mean that a large portion of users would *not be able to
>  install Fedora*.
>  
Just note that I mean blocking by "supported". I am not talking about
dropping capability of installation from optical media. Might have been
slight misunderstanding and bad wording on my side. Also, I doubt that your
"large portion" is correct.


>  UNetbootin has never been a supported method of creating USB media.
>  Optical media is a supported installation method.
>  
It doesn't matter what was or wasn't supported. WIth definition of what I
mean with "supported" above, if this proposal is accepted, UNetbootin
wouldn't be supported too differently than physical optical media. Users
would be able to report bugs with these methods and those bugs wouldn't be
release blocking.

Practically speaking, I'd say that adding the same warning as is in
UNetbootin section in Fedora Docs [0] to the Live CD section [1] would make
sense, but this is just an idea and probably out of scope of this thread.

[0]
https://docs.fedoraproject.org/en-US/quick-docs/creating-and-using-a-live...
[1]
https://docs.fedoraproject.org/en-US/quick-docs/creating-and-using-a-live...

[Kevin Kofler]

Frantisek Zatloukal wrote:
>  Just note that I mean blocking by "supported". I am not
> talking about
>  dropping capability of installation from optical media. 
But if:
* QA does not test it, and
* even if somebody tests it and finds it broken, the release will not get
  delayed for it,
this can effectively break at any time, for an entire release, just because 
you happen to release in the wrong moment and are not willing to wait.

        Kevin Kofler

[Chris Murphy]

On Sun, Dec 15, 2019 at 2:32 PM Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote:
>  Frantisek Zatloukal wrote:
>  > Just note that I mean blocking by "supported". I am not talking about
>  > dropping capability of installation from optical media.
>
>  But if:
>  * QA does not test it, and
>  * even if somebody tests it and finds it broken, the release will not get
>    delayed for it,
>  this can effectively break at any time, for an entire release, just because
>  you happen to release in the wrong moment and are not willing to wait. 
Possible, but not probable, based on the historical record. And even
if not a blocker, tested fixes would surely be granted a freeze
exception.

But therein lies the advantage of a simpler optical only image, less
likelihood for such regressions. And any netinstall can be pointed to
any release repo, so it's not like you must have a release version of
the image - in the worst case scenario you still wouldn't be
abandoned. Further, the netinstall has the installer rescue boot
option.


-- 
Chris Murphy

[Kevin Kofler]

Chris Murphy wrote:
>  But therein lies the advantage of a simpler optical only image, less
>  likelihood for such regressions. And any netinstall can be pointed to
>  any release repo, so it's not like you must have a release version of
>  the image - in the worst case scenario you still wouldn't be
>  abandoned. Further, the netinstall has the installer rescue boot
>  option. 
The netinstall:
* is not usable offline,
* in particular, is a pain to set up if all you have is a WPA-protected
  WLAN,
* or in particular, will not work at all if your WiFi chipset requires a
  non-upstream (either proprietary, or not submitted upstream yet, or stuck
  in staging) driver,
* does not provide a live environment, so you cannot try it out before the
  installation is complete,
* has only a minimal rescue environment that is actually often not as nice
  to use for rescue purposes as a graphical live environment,
* does not install the exact set of packages the live image ships, and there
  are technical limitations that do not allow as much fine-tuning as in the
  live kickstart (e.g., there is no way for us to tell the netinstall that
  KDE users will not need some tools from the System Administration group
  that have KDE equivalents, whereas the live kickstart can explicitly
  blacklist unneeded packages).

        Kevin Kofler

[Ryan Walklin]

On Mon, 16 Dec 2019, at 1:39 PM, John M. Harris Jr wrote:

>  Please see the examples cited earlier in the thread, of systems that
> cannot be 
>  installed from USB. 
Those are pretty vague references to old workstations and servers rather than specific
make/model. Can you not use a generic rescue DVD/CD running something like rEFInd
http://www.rodsbooks.com/refind to then actually boot from USB? Then you wouldn't have
to faff keeping your optical media up to date anyway.

https://www.kubuntuforums.net/showthread.php/43221-GRUB-2-A-Guide-for-Use...

On Mon, 16 Dec 2019, at 1:45 PM, Kevin Kofler wrote:

>  The netinstall:
>  * is not usable offline,
>  * in particular, is a pain to set up if all you have is a WPA-protected
>    WLAN,
>  * or in particular, will not work at all if your WiFi chipset requires a
>    non-upstream (either proprietary, or not submitted upstream yet, or stuck
>    in staging) driver, 
As a tangent. this is pretty annoying, even when installing from USB I have to manually go
out and grab firmware and NetworkManager packages for my laptop. Even worse they seem to
be installed on the live images themselves and so WiFi works in Anaconda but not in the
installed system.

[John M. Harris Jr]

On Sunday, December 15, 2019 7:54:05 PM MST Ryan Walklin wrote:
>  On Mon, 16 Dec 2019, at 1:39 PM, John M. Harris Jr wrote:
>  
>  
>  > Please see the examples cited earlier in the thread, of systems that
>  > cannot be installed from USB.
>  
>  
>  Those are pretty vague references to old workstations and servers rather
>  than specific make/model. 
I can provide an example or two, but I'd rather not waste time compiling a 
list. A good example, any server using iDRAC6,7,8 or 9, such as a PowerEdge 
R440. These are in the interesting edge case that I mentioned, where it 
supports USB boot if you physically connect a USB drive, but you can't use USB 
images over the iDRAC. An example of a system that cannot boot from USB at all 
is a ThinkPad T400, running default boot firmware, which is what most users 
that own that laptop would have.

>  Can you not use a generic rescue DVD/CD running
>  something like rEFInd http://www.rodsbooks.com/refind to then actually boot
>  from USB? Then you wouldn't have to faff keeping your optical media up to
>  date anyway. 
I have no idea whether or not that'd work, but I generally don't mess around 
with random tools like that to try to get something to boot. Looks like it 
requires UEFI, so I'm going to go with "Not in most cases", though it might

work for the systems with UEFI implementations that don't support USB boot. 
When I'm wearing my user hat, I just want it to work! It currently does, and 
it doesn't actually take a lot of maintenance to keep it working. I'd be happy 
to jump on the list of people doing QA of physical DVDs, so long as we can 
keep it as release-blocking, because this WILL hurt users if it is dropped, 
and we WILL have a release with broken optical media installation, most likely 
in the first release to adopt this Change.

-- 
John M. Harris, Jr.
Splentity

[Chris Adams]

Once upon a time, John M. Harris Jr <johnmh(a)splentity.com&gt; said:
>  I can provide an example or two, but I'd rather not waste time
> compiling a 
>  list. A good example, any server using iDRAC6,7,8 or 9, such as a PowerEdge 
>  R440. These are in the interesting edge case that I mentioned, where it 
>  supports USB boot if you physically connect a USB drive, but you can't use USB 
>  images over the iDRAC. 
Virtual media is not relevant to this change (ISOs will still be
tested), but I'm not sure what you even mean by "USB images over the
iDRAC".  I re-installed some old R610s (DRAC6) Friday by booting from a
virtual CD connected to an ISO image file, and they worked just fine.

-- 
Chris Adams <linux(a)cmadams.net&gt;

[John M. Harris Jr]

On Sunday, December 15, 2019 8:12:55 PM MST Chris Adams wrote:
>  Once upon a time, John M. Harris Jr <johnmh(a)splentity.com&gt;
> said:
>  
>  > I can provide an example or two, but I'd rather not waste time compiling a
>  >  list. A good example, any server using iDRAC6,7,8 or 9, such as a
>  > PowerEdge R440. These are in the interesting edge case that I mentioned,
>  > where it supports USB boot if you physically connect a USB drive, but you
>  > can't use USB images over the iDRAC.
>  
>  
>  Virtual media is not relevant to this change (ISOs will still be
>  tested), but I'm not sure what you even mean by "USB images over the
>  iDRAC".  I re-installed some old R610s (DRAC6) Friday by booting from a
>  virtual CD connected to an ISO image file, and they worked just fine. 
That would be affected by this change, as... that's a virtual CD. It'd have to 
be a valid, working CD image.

-- 
John M. Harris, Jr.
Splentity

[Chris Adams]

Once upon a time, John M. Harris Jr <johnmh(a)splentity.com&gt; said:
>  That would be affected by this change, as... that's a virtual CD.
> It'd have to 
>  be a valid, working CD image. 
This change is about only physical optical media, not the ISO images.
-- 
Chris Adams <linux(a)cmadams.net&gt;

[John M. Harris Jr]

On Sunday, December 15, 2019 8:44:29 PM MST Chris Adams wrote:
>  Once upon a time, John M. Harris Jr <johnmh(a)splentity.com&gt;
> said:
>  
>  > That would be affected by this change, as... that's a virtual CD. It'd
>  > have to be a valid, working CD image.
>  
>  
>  This change is about only physical optical media, not the ISO images. 
This change is about testing those ISO images, and whether or not those ISO 
images are release-blocking. If it's not a valid CD image (meaning it wouldn't 
boot when put into a real disk drive), it most likely wouldn't work in the 
virtual CD images.

It definitely wouldn't work in something like a T400 running the boot firmware 
provided by Lenovo, where you've got to drop a working CD/DVD into the drive 
to boot from external media. This also doesn't solve anything for the users 
that have first or second generation UEFI systems, or those with UEFI firmware 
provided by a vendor, that doesn't support USB boot.

Instead of trying to attack CD/DVD installs, why not keep what's working in 
the state it's already in?

-- 
John M. Harris, Jr.
Splentity

[Chris Adams]

Once upon a time, John M. Harris Jr <johnmh(a)splentity.com&gt; said:
>  This change is about testing those ISO images, and whether or not
> those ISO 
>  images are release-blocking. If it's not a valid CD image (meaning it wouldn't 
>  boot when put into a real disk drive), it most likely wouldn't work in the 
>  virtual CD images. 
No, it is just about not writing those ISO images to physical media for
testing.  The ISO images will still be blocking deliverables.  Testing
of ISOs is easy and can be done automated.  Testing of physical media
requires time.

>  This also doesn't solve anything for the users 
>  that have first or second generation UEFI systems, or those with UEFI firmware 
>  provided by a vendor, that doesn't support USB boot. 
So again, if UEFI boot doesn't work, don't use it?  I tried UEFI boot
with an early generation, and it had multiple issues, so I stuck with
BIOS boot for a while longer.  There's nothing in Fedora that requires
UEFI boot.

>  Instead of trying to attack CD/DVD installs, why not keep what's
> working in 
>  the state it's already in? 
Because it's a time-consuming and manual process, and resources are
limited?
-- 
Chris Adams <linux(a)cmadams.net&gt;

[John M. Harris Jr]

On Sunday, December 15, 2019 9:03:43 PM MST Chris Adams wrote:
>  Once upon a time, John M. Harris Jr <johnmh(a)splentity.com&gt;
> said:
>  
>  > This change is about testing those ISO images, and whether or not those
>  > ISO  images are release-blocking. If it's not a valid CD image (meaning
>  > it wouldn't boot when put into a real disk drive), it most likely
>  > wouldn't work in the virtual CD images.
>  
>  
>  No, it is just about not writing those ISO images to physical media for
>  testing.  The ISO images will still be blocking deliverables.  Testing
>  of ISOs is easy and can be done automated.  Testing of physical media
>  requires time.
>  
>  
>  > This also doesn't solve anything for the users 
>  > that have first or second generation UEFI systems, or those with UEFI
>  > firmware  provided by a vendor, that doesn't support USB boot.
>  
>  
>  So again, if UEFI boot doesn't work, don't use it?  I tried UEFI boot
>  with an early generation, and it had multiple issues, so I stuck with
>  BIOS boot for a while longer.  There's nothing in Fedora that requires
>  UEFI boot. 
I didn't say that anything in Fedora required UEFI boot. For example, none of 
my systems that run GNU/Linux actually have UEFI. However, there are a number 
of systems that don't support booting from USB in UEFI or BIOS, or only 
implement UEFI and not BIOS, or only BIOS and not UEFI but don't have USB 
support. It's not a solution to simply say "Go grab this third party software 
to bootstrap your Fedora installation". Put on the user hat for a minute and 
think about how this actually affects those users.

>  > Instead of trying to attack CD/DVD installs, why not keep
> what's working
>  > in  the state it's already in?
>  
>  
>  Because it's a time-consuming and manual process, and resources are
>  limited? 
I've outlined how much time it takes. I'd happily take on that responsibility 
myself, but we need to make sure we're not kneecapping users for no real 
reason.


-- 
John M. Harris, Jr.
Splentity

[Ryan Walklin]

>  I can provide an example or two, but I'd rather not waste time
> compiling a 
>  list. A good example, any server using iDRAC6,7,8 or 9, such as a PowerEdge 
>  R440. These are in the interesting edge case that I mentioned, where it 
>  supports USB boot if you physically connect a USB drive, but you can't use USB 
>  images over the iDRAC. An example of a system that cannot boot from USB at all 
>  is a ThinkPad T400, running default boot firmware, which is what most users 
>  that own that laptop would have. 
I don't have experience with either system, but as Chris points out, virtual CD ISOs
seem to work. A quick google suggests the ThinkPad T400 can both boot and upgrade its
firmware/BIOS via USB.

>  
>  > Can you not use a generic rescue DVD/CD running
>  > something like rEFInd http://www.rodsbooks.com/refind to then actually boot
>  > from USB? Then you wouldn't have to faff keeping your optical media up to
>  > date anyway.
>  
>  I have no idea whether or not that'd work, but I generally don't mess around 
>  with random tools like that to try to get something to boot.  
It's a combination of the standard TianoCore/ED2K UEFI implementation with a handy
UI/boot menu. I'm just making the point that you can use a combination of a rescue CD
which doesn't need to be constantly upgraded and a USB-based OS install if you need to
reinstall with physical media.

[John M. Harris Jr]

On Sunday, December 15, 2019 8:36:15 PM MST Ryan Walklin wrote:
>  It's a combination of the standard TianoCore/ED2K UEFI
> implementation with a
>  handy UI/boot menu. I'm just making the point that you can use a
>  combination of a rescue CD which doesn't need to be constantly upgraded and
>  a USB-based OS install if you need to reinstall with physical media. 
At $WORK, I probably burn 20 CDs in a given month, sometimes several times 
that, if I'm doing updates. Making a new CD every 6 months somehow doesn't 
concern me, and as cheap as CDs are, I don't think this is something that 
hurts users.

Instead of trying to make arguments against those who use CDs, why not keep 
what already works maintained? The level of effort required here is 
surprisingly small, testing installation from a physical CD takes, with a SATA 
II connection to a hard drive, approximately 25 minutes, and only ~2 minutes 
of that require user interaction. Actually less, if using default options. 
From there, the only requirement is clicking "Reboot" and waiting for the 
installed system to boot. At most, in addition, it'd require logging in with 
the user you've set up. That's less than an hour total, and it only needs to 
be done after automated tests with virtual CDs pass.

-- 
John M. Harris, Jr.
Splentity

[Adam Williamson]

On Sun, 2019-12-15 at 20:48 -0700, John M. Harris Jr wrote:
>  Instead of trying to make arguments against those who use CDs, why
> not keep 
>  
>  what already works maintained? The level of effort required here is 
>  
>  surprisingly small, testing installation from a physical CD takes, with a SATA 
>  
>  II connection to a hard drive, approximately 25 minutes, and only ~2 minutes 
>  
>  of that require user interaction. 
This is not accurate. You're not accounting for the time it takes to
write the disc, and we also have to check that the media check works,
which takes quite a while on its own.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[John M. Harris Jr]

On Monday, December 16, 2019 9:56:01 AM MST Adam Williamson wrote:
>  This is not accurate. You're not accounting for the time it takes
> to
>  write the disc, and we also have to check that the media check works,
>  which takes quite a while on its own. 
I was accounting for that time. Writing to a disk and checking it does not 
take a long time, ~20 minutes at most. This is why I said "less than an hour" 
in total. Additionally, during that time, no user interaction is required, 
once the process is started.

-- 
John M. Harris, Jr.
Splentity

[Kamil Paral]

On Mon, Dec 16, 2019 at 6:14 PM John M. Harris Jr <johnmh(a)splentity.com&gt;
wrote:

>  On Monday, December 16, 2019 9:56:01 AM MST Adam Williamson wrote:
>  > This is not accurate. You're not accounting for the time it takes to
>  > write the disc, and we also have to check that the media check works,
>  > which takes quite a while on its own.
>
>  I was accounting for that time. Writing to a disk and checking it does not
>  take a long time, ~20 minutes at most. This is why I said "less than an
>  hour"
>  in total. Additionally, during that time, no user interaction is required,
>  once the process is started.
>  
I guess I should provide some better data for those estimated time
requirements. I haven't used a stopwatch during the last release cycle, but
my estimate is that it takes 1-1.5 hours to check a single install medium.
This includes burning the DVD, booting it in BIOS mode including the
mandatory and default media check, performing the installation, and then
repeating the boot and install in UEFI mode. Occasionally there are some
optical reading-related issues, e.g. when a machine gets stuck because it
constantly spins up and spins down the disc, having a problem trying to
read some area. Sometimes the disc access gets unusably slow, just to work
fine after a reboot. All the usual stuff that you come across when using
CDs/DVDs. Some of that is definitely caused by our rewritable media being
scratched, or DVD drives being old and the laser no longer being well
calibrated. We'd have to buy new drives to improve that experience, but I
don't really see much sense in that, when optical media is a niche
technology nowadays (hence this proposal).

We have 2 release-blocking media, so the total time is somewhere between
2-3 hours (likely closer to 2 hours, because netinst installation is way
faster due to downloading packages from the net instead of copying them
from the disc). That's not the main problem, though. The main problem is
that during that time, one or two of our test machines in our office is
fully occupied with spinning the discs, and we can't use it for anything
else. That means all other bare-metal testing needs to wait. As Adam
already pointed out, sometimes we need to check the final candidate
composes in a single day, i.e. in the standard 8 working hours (and yes, we
often work overtime in these cases). Blocking half of our bare-metal office
test machines for 2 hours out of 8 is not a small deal.

It's simple to say "no user interaction is required", but that's not
completely true either. If you want to do the QA job properly, you need to
have an eye on the media consistency check, because we've had issues in the
past where it timed out and either considered it a pass or fail (both are
incorrect). So you can't simply walk away and come back and consider it OK
when it reached the installer, you really need to watch the progress in
certain critical points. Once the UI is ready, it is much slower than when
booting from USB. So you often spend 10, 20 seconds staring at the screen
until it decides to do something. The actual installation progress is
unattended yet. But you need to check it frequently to see whether it
finished, so that you don't waste time of the bare metal machine standing
idle. There are many more tests waiting in the queue.

The fact that this whole process is a major annoyance (it really makes you
hate optical media, if you deal with this regularly) is of course
contributing to the fact that we don't want to do it anymore. We're only
humans. But we wouldn't have proposed the criterion change if we hadn't
thought the time is right and that it is no longer an important factor for
the majority of our users. We've waited very long with this proposal. And I
still intend to keep testing optical media functionality from time to time,
even when optical-blocking criterion is removed. But I'll do it once or
twice per cycle, probably with a Beta GO compose, and not for every release
candidate created.

[John M. Harris Jr]

On Monday, December 16, 2019 12:52:49 PM MST Kamil Paral wrote:
>  On Mon, Dec 16, 2019 at 6:14 PM John M. Harris Jr
> <johnmh(a)splentity.com&gt;
>  
>  wrote:
>  > On Monday, December 16, 2019 9:56:01 AM MST Adam Williamson wrote:
>  > > This is not accurate. You're not accounting for the time it takes to
>  > > write the disc, and we also have to check that the media check works,
>  > > which takes quite a while on its own.
>  > 
>  > I was accounting for that time. Writing to a disk and checking it does not
>  > take a long time, ~20 minutes at most. This is why I said "less than an
>  > hour"
>  > in total. Additionally, during that time, no user interaction is required,
>  > once the process is started.
>  
>  I guess I should provide some better data for those estimated time
>  requirements. I haven't used a stopwatch during the last release cycle, but
>  my estimate is that it takes 1-1.5 hours to check a single install medium.
>  This includes burning the DVD, booting it in BIOS mode including the
>  mandatory and default media check, performing the installation, and then
>  repeating the boot and install in UEFI mode. Occasionally there are some
>  optical reading-related issues, e.g. when a machine gets stuck because it
>  constantly spins up and spins down the disc, having a problem trying to
>  read some area. Sometimes the disc access gets unusably slow, just to work
>  fine after a reboot. All the usual stuff that you come across when using
>  CDs/DVDs. Some of that is definitely caused by our rewritable media being
>  scratched, or DVD drives being old and the laser no longer being well
>  calibrated. We'd have to buy new drives to improve that experience, but I
>  don't really see much sense in that, when optical media is a niche
>  technology nowadays (hence this proposal). 
It is simply not the case that optical media is niche, especially not in 
enterprise installations, low end consumer, business class systems or new old 
stock systems. For example, at $WORK, we use optical media for all 

>  We have 2 release-blocking media, so the total time is somewhere
> between
>  2-3 hours (likely closer to 2 hours, because netinst installation is way
>  faster due to downloading packages from the net instead of copying them
>  from the disc). That's not the main problem, though. The main problem is
>  that during that time, one or two of our test machines in our office is
>  fully occupied with spinning the discs, and we can't use it for anything
>  else. That means all other bare-metal testing needs to wait. As Adam
>  already pointed out, sometimes we need to check the final candidate
>  composes in a single day, i.e. in the standard 8 working hours (and yes, we
>  often work overtime in these cases). Blocking half of our bare-metal office
>  test machines for 2 hours out of 8 is not a small deal. 
Do you need more test hardware? Honestly, that's what this sounds like.

>  It's simple to say "no user interaction is required",
> but that's not
>  completely true either. If you want to do the QA job properly, you need to
>  have an eye on the media consistency check, because we've had issues in the
>  past where it timed out and either considered it a pass or fail (both are
>  incorrect). So you can't simply walk away and come back and consider it OK
>  when it reached the installer, you really need to watch the progress in
>  certain critical points. Once the UI is ready, it is much slower than when
>  booting from USB. So you often spend 10, 20 seconds staring at the screen
>  until it decides to do something. 
Is that due to the hardware under test, or is it a result of scratched media?

>  The actual installation progress is unattended yet. But you need to
> check it
>  frequently to see whether it finished, so that you don't waste time of the
>  bare metal machine standing idle. There are many more tests waiting in the
>  queue. 
>  The fact that this whole process is a major annoyance (it really
> makes you
>  hate optical media, if you deal with this regularly) is of course
>  contributing to the fact that we don't want to do it anymore. We're only
>  humans. But we wouldn't have proposed the criterion change if we hadn't
>  thought the time is right and that it is no longer an important factor for
>  the majority of our users. We've waited very long with this proposal. And I
>  still intend to keep testing optical media functionality from time to time,
>  even when optical-blocking criterion is removed. But I'll do it once or
>  twice per cycle, probably with a Beta GO compose, and not for every release
>  candidate created. 
I'd happily volunteer to help test this, but this is the standard method of 
installing in many environments, and is also the ONLY option in a good number 
of environments as we've described.

-- 
John M. Harris, Jr.
Splentity

[Kamil Paral]

On Tue, Dec 17, 2019 at 12:23 AM John M. Harris Jr <johnmh(a)splentity.com&gt;
wrote:

>  > We have 2 release-blocking media, so the total time is somewhere
> between
>  > 2-3 hours (likely closer to 2 hours, because netinst installation is way
>  > faster due to downloading packages from the net instead of copying them
>  > from the disc). That's not the main problem, though. The main problem is
>  > that during that time, one or two of our test machines in our office is
>  > fully occupied with spinning the discs, and we can't use it for anything
>  > else. That means all other bare-metal testing needs to wait. As Adam
>  > already pointed out, sometimes we need to check the final candidate
>  > composes in a single day, i.e. in the standard 8 working hours (and yes,
>  we
>  > often work overtime in these cases). Blocking half of our bare-metal
>  office
>  > test machines for 2 hours out of 8 is not a small deal.
>
>  Do you need more test hardware? Honestly, that's what this sounds like.
>  
Not really. Our office cubicle is unfortunately not inflatable. We have 2-3
dedicated bare-metal test machines available during the test cycle, and we
can't really fit any more.


>  > It's simple to say "no user interaction is required", but that's
> not
>  > completely true either. If you want to do the QA job properly, you need
>  to
>  > have an eye on the media consistency check, because we've had issues in
>  the
>  > past where it timed out and either considered it a pass or fail (both are
>  > incorrect). So you can't simply walk away and come back and consider it
>  OK
>  > when it reached the installer, you really need to watch the progress in
>  > certain critical points. Once the UI is ready, it is much slower than
>  when
>  > booting from USB. So you often spend 10, 20 seconds staring at the screen
>  > until it decides to do something.
>
>  Is that due to the hardware under test, or is it a result of scratched
>  media?
>  
Due to the fact that optical media are just glacially slow. I don't know if
you have ever tried Workstation Live from a fast USB3 media, but the
difference is night and day.

[John M. Harris Jr]

On Tuesday, December 17, 2019 2:33:06 AM MST Kamil Paral wrote:
>  On Tue, Dec 17, 2019 at 12:23 AM John M. Harris Jr
> <johnmh(a)splentity.com&gt;
>  
>  wrote:
>  > > We have 2 release-blocking media, so the total time is somewhere between
>  > > 2-3 hours (likely closer to 2 hours, because netinst installation is way
>  > > faster due to downloading packages from the net instead of copying them
>  > > from the disc). That's not the main problem, though. The main problem is
>  > > that during that time, one or two of our test machines in our office is
>  > > fully occupied with spinning the discs, and we can't use it for anything
>  > > else. That means all other bare-metal testing needs to wait. As Adam
>  > > already pointed out, sometimes we need to check the final candidate
>  > > composes in a single day, i.e. in the standard 8 working hours (and yes,
>  > 
>  > we
>  > 
>  > > often work overtime in these cases). Blocking half of our bare-metal
>  > 
>  > office
>  > 
>  > > test machines for 2 hours out of 8 is not a small deal.
>  > 
>  > Do you need more test hardware? Honestly, that's what this sounds like.
>  
>  Not really. Our office cubicle is unfortunately not inflatable. We have 2-3
>  dedicated bare-metal test machines available during the test cycle, and we
>  can't really fit any more.
>  
>  > > It's simple to say "no user interaction is required", but
> that's not
>  > > completely true either. If you want to do the QA job properly, you need
>  > 
>  > to
>  > 
>  > > have an eye on the media consistency check, because we've had issues in
>  > 
>  > the
>  > 
>  > > past where it timed out and either considered it a pass or fail (both
>  > > are
>  > > incorrect). So you can't simply walk away and come back and consider it
>  > 
>  > OK
>  > 
>  > > when it reached the installer, you really need to watch the progress in
>  > > certain critical points. Once the UI is ready, it is much slower than
>  > 
>  > when
>  > 
>  > > booting from USB. So you often spend 10, 20 seconds staring at the
>  > > screen
>  > > until it decides to do something.
>  > 
>  > Is that due to the hardware under test, or is it a result of scratched
>  > media?
>  
>  Due to the fact that optical media are just glacially slow. I don't know if
>  you have ever tried Workstation Live from a fast USB3 media, but the
>  difference is night and day. 
Optical media is not *that* slow though. There's certainly a difference, but 
optical isn't so slow that you have to stare at a blank screen while it loads.

-- 
John M. Harris, Jr.
Splentity

[Kevin Kofler]

Adam Williamson wrote:
>  This is not accurate. You're not accounting for the time it takes
> to
>  write the disc, and we also have to check that the media check works,
>  which takes quite a while on its own. 
Who cares whether the media check works? If it fails, but the distro still 
installs, that is not a blocker. I remember how, in the early Fedora days, 
it was entirely normal that the media check would always fail and that we 
all learned to just skip it and stop wasting our time on it. (And if it is 
such a time sink, I would argue to just drop it and boot directly to the 
installer.)

        Kevin Kofler

[Kamil Paral]

On Mon, Dec 16, 2019 at 7:50 PM Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote:

>  Adam Williamson wrote:
>  > This is not accurate. You're not accounting for the time it takes to
>  > write the disc, and we also have to check that the media check works,
>  > which takes quite a while on its own.
>
>  Who cares whether the media check works? If it fails, but the distro still
>  installs, that is not a blocker. 

You might not want to speak with such certainty about things you're not
completely familiar with:
https://fedoraproject.org/wiki/Fedora_31_Final_Release_Criteria#Media_con...

If you wanted to say "that should not be a blocker", you're welcome to
propose that change and we'll discuss it, but please do it in a separate
thread.

[John M. Harris Jr]

On Monday, December 16, 2019 11:48:49 AM MST Kevin Kofler wrote:
>  Adam Williamson wrote:
>  
>  > This is not accurate. You're not accounting for the time it takes to
>  > write the disc, and we also have to check that the media check works,
>  > which takes quite a while on its own.
>  
>  
>  Who cares whether the media check works? If it fails, but the distro still 
>  installs, that is not a blocker. I remember how, in the early Fedora days,
>  it was entirely normal that the media check would always fail and that we
>  all learned to just skip it and stop wasting our time on it. (And if it is
>  such a time sink, I would argue to just drop it and boot directly to the
>  installer.) 
Generally, I'd have to agree with this. I have still skipped it in every 
installation I've done, and I'm pretty sure it actually works now.

-- 
John M. Harris, Jr.
Splentity

[Chris Murphy]

On Sun, Dec 15, 2019 at 7:55 PM Ryan Walklin <ryan(a)testtoast.com&gt; wrote:
>  On Mon, 16 Dec 2019, at 1:45 PM, Kevin Kofler wrote:
>
>  > The netinstall:
>  > * is not usable offline,
>  > * in particular, is a pain to set up if all you have is a WPA-protected
>  >   WLAN,
>  > * or in particular, will not work at all if your WiFi chipset requires a
>  >   non-upstream (either proprietary, or not submitted upstream yet, or stuck
>  >   in staging) driver,
>
>  As a tangent. this is pretty annoying, even when installing from USB I have to manually
> go out and grab firmware and NetworkManager packages for my laptop. Even worse they seem
> to be installed on the live images themselves and so WiFi works in Anaconda but not in the
> installed system. 
That sounds like two bugs, each needing their own bug reports:
a. the difference in wifi firmware offerings between netinstall and Live
b. that it works on Live but not once installed from Live (this is an
rsync copy, with an immutable RPM database so it's not likely a case
of missing firmware, maybe some NetworkManager bug or some problem
with a kernel module not loading or a race that only happens on the
installed systems? Needs troubleshooting comparing Live and installed
boots.

Feel free to post URLs for this on desktop@ list.

Some wifi hardware requires firmware with license restrictions
preventing including in Fedora (I'm looking at Broadcom) but that's a
known problem with not many good work arounds.
https://pagure.io/fedora-workstation/issue/116


-- 
Chris Murphy

[Kevin Kofler]

Ryan Walklin wrote:
>  Those are pretty vague references to old workstations and servers
> rather
>  than specific make/model. Can you not use a generic rescue DVD/CD running
>  something like rEFInd http://www.rodsbooks.com/refind to then actually
>  boot from USB? Then you wouldn't have to faff keeping your optical media
>  up to date anyway. 
Surely that is not an officially supported (by Fedora) boot method and as 
such can also break at any time. And some of the bugs that prevent booting 
directly from optical media will also prevent booting from such a setup. 
(E.g., if it is the fact that there is an optical media inserted that 
confuses the listing of potential target devices in Anaconda.)

>  As a tangent. this is pretty annoying, even when installing from USB
> I
>  have to manually go out and grab firmware and NetworkManager packages for
>  my laptop. Even worse they seem to be installed on the live images
>  themselves and so WiFi works in Anaconda but not in the installed system. 
I don't really see how that can happen. The liveinst mode of Anaconda just 
rsyncs everything that is installed on the live image to the target disk. It 
is not going to exclude firmware or any other installed packages. (Not even 
Anaconda itself, despite it not being needed on the installed system.)

        Kevin Kofler

[John M. Harris Jr]

On Sunday, December 15, 2019 1:53:15 PM MST Frantisek Zatloukal wrote:
>  On Sun, Dec 15, 2019 at 9:05 PM John M. Harris Jr
> <johnmh(a)splentity.com&gt;
>  
>  wrote:
>  > That was not brought up elsewhere in this thread. Who is considering this,
>  > and
>  > why? That would mean that a large portion of users would *not be able to
>  > install Fedora*.
>  
>  Just note that I mean blocking by "supported". I am not talking about
>  dropping capability of installation from optical media. Might have been
>  slight misunderstanding and bad wording on my side. Also, I doubt that your
>  "large portion" is correct. 
As explained earlier in this thread, DVD drives are still a standard offering 
on prebuilt systems. In fact, I just checked, and they're a standard offering 
on ALL of the current line Dell workstations which are RHEL certified.

>  > UNetbootin has never been a supported method of creating USB
> media.
>  > Optical media is a supported installation method.
>  
>  It doesn't matter what was or wasn't supported. WIth definition of what I
>  mean with "supported" above, if this proposal is accepted, UNetbootin
>  wouldn't be supported too differently than physical optical media. Users
>  would be able to report bugs with these methods and those bugs wouldn't be
>  release blocking.
>  
>  Practically speaking, I'd say that adding the same warning as is in
>  UNetbootin section in Fedora Docs [0] to the Live CD section [1] would make
>  sense, but this is just an idea and probably out of scope of this thread. 
I have no idea why you'd do that, nor why anyone would want to do it. That'd 
be like telling folks installing from DVD images isn't the right thing to do, 
which makes no sense, as it's the standard way to install any system, and has 
been since the mid 2000s.

-- 
John M. Harris, Jr.
Splentity

[Chris Murphy]

On Sun, Dec 15, 2019 at 4:39 PM John M. Harris Jr <johnmh(a)splentity.com&gt; wrote:
>  On Sunday, December 15, 2019 1:53:15 PM MST Frantisek Zatloukal wrote:
>  > On Sun, Dec 15, 2019 at 9:05 PM John M. Harris Jr <johnmh(a)splentity.com&gt;
>  >
>  > wrote:
>  > > That was not brought up elsewhere in this thread. Who is considering this,
>  > > and
>  > > why? That would mean that a large portion of users would *not be able to
>  > > install Fedora*.
>  >
>  > Just note that I mean blocking by "supported". I am not talking about
>  > dropping capability of installation from optical media. Might have been
>  > slight misunderstanding and bad wording on my side. Also, I doubt that your
>  > "large portion" is correct.
>
>  As explained earlier in this thread, DVD drives are still a standard offering
>  on prebuilt systems. In fact, I just checked, and they're a standard offering
>  on ALL of the current line Dell workstations which are RHEL certified. 
I spent about 15 minutes on this and found exactly zero systems with
DVD drives, even as an option, on the Apple and Microsoft stores. None
for System76. And none for HP. I did find DVD drives a custom build
option on Dell's website. But even if there are some ways to dig
around for systems with optical drives, it's not at all persuasive
that it's common or typical or standard on prebuilt systems.

Three years ago I did a more involved search when looking for a new
laptop. Zero optical drives in new hardware. Only as external
accessory add-ons. Of course my search was biased in favor of weight.
Whereas your search is biased for workstations. Based on user forums
and bug reports, laptops are a significant portion of the user base,
so to discount them entirely isn't convincing.

A simple google search on the death of optical drives turns up 51
million results, the first page includes:

Death of the Computer Optical Drive
Why most modern PCs don't feature CD, DVD, or Blu-ray drives  - 2019, Lifewire

Why you might still want an optical drive - 2015, PC Magazine

The End of Optical Storage? It’s Here - 2012, Network World

Our broad heterogeneous user based probably does have more dependency
on optical drives than recent hardware trends indicate. But I don't
buy the idea at all that optical drives are still in their heyday.



>  > Practically speaking, I'd say that adding the same warning
> as is in
>  > UNetbootin section in Fedora Docs [0] to the Live CD section [1] would make
>  > sense, but this is just an idea and probably out of scope of this thread.
>
>  I have no idea why you'd do that, nor why anyone would want to do it. That'd
>  be like telling folks installing from DVD images isn't the right thing to do,
>  which makes no sense, as it's the standard way to install any system, and has
>  been since the mid 2000s. 
Optical drives are the exception, rather than the rule. Clicking
around on Dell's sight for desktops, I tried to click the middle
option each time, neither high nor low end. I get

Dell Precision 5280 $1629, six hard drive bays, optical drive not
included, but is available as an option. Windows optical media is not
included. But there is a single option to get it, on USB. It's not an
option to get it on a DVD.

But you're saying it's standard way to install any system. Gotcha.


-- 
Chris Murphy

[John M. Harris Jr]

On Sunday, December 15, 2019 5:13:22 PM MST Chris Murphy wrote:
>  I spent about 15 minutes on this and found exactly zero systems with
>  DVD drives, even as an option, on the Apple and Microsoft stores. None
>  for System76. And none for HP. I did find DVD drives a custom build
>  option on Dell's website. But even if there are some ways to dig
>  around for systems with optical drives, it's not at all persuasive
>  that it's common or typical or standard on prebuilt systems. 
What were you looking at? I don't know about Apple, nor how that's relevant, 
since installing a new OS on those systems invalidates the hardware warranty, 
and I didn't even know Microsoft sold hardware. As for System76, I recently 
purchased a laptop from them, their Darter Pro. It even has an option, when 
buying the device, to include an external optical drive, because they 
understand it's a feature that many people still rely on.

I just checked for the consumer side, both Walmart and Best Buy's offerings. 
My findings are expanded in the section below.

>  Three years ago I did a more involved search when looking for a new
>  laptop. Zero optical drives in new hardware. Only as external
>  accessory add-ons. Of course my search was biased in favor of weight.
>  Whereas your search is biased for workstations. Based on user forums
>  and bug reports, laptops are a significant portion of the user base,
>  so to discount them entirely isn't convincing. 
While some newer laptops will still have the optical drive integrated, in the 
interest of going to "slim" designs, many manufacturers have started offering 
external drives with their systems as a way of losing some of that, or moving 
to weird slit-style drives, where you push the drive into the system, instead 
of actually opening a drive door. The laptops that still have them integrated 
are the business class lines, as well as the low end consumer offerings.

What's weird, to me, is that the mid to high-end consumer devices don't have 
them, but the lower-end ones still do. Could be new old stock.

>  A simple google search on the death of optical drives turns up 51
>  million results, the first page includes:
>  
>  Death of the Computer Optical Drive
>  Why most modern PCs don't feature CD, DVD, or Blu-ray drives  - 2019,
>  Lifewire
>
>  Why you might still want an optical drive - 2015, PC Magazine
>  
>  The End of Optical Storage? It’s Here - 2012, Network World 
I've seen these articles as well, but it's just not in line with where we 
actually are.

>  Our broad heterogeneous user based probably does have more
> dependency
>  on optical drives than recent hardware trends indicate. But I don't
>  buy the idea at all that optical drives are still in their heyday. 
They're not really in their heyday anymore, but they are still incredibly 
common.

>  > > Practically speaking, I'd say that adding the same
> warning as is in
>  > > UNetbootin section in Fedora Docs [0] to the Live CD section [1] would
>  > > make sense, but this is just an idea and probably out of scope of this
>  > > thread.>
>  >
>  >
>  > I have no idea why you'd do that, nor why anyone would want to do it.
>  > That'd be like telling folks installing from DVD images isn't the right
>  > thing to do, which makes no sense, as it's the standard way to install
>  > any system, and has been since the mid 2000s.
>  
>  
>  Optical drives are the exception, rather than the rule. Clicking
>  around on Dell's sight for desktops, I tried to click the middle
>  option each time, neither high nor low end. I get
>  
>  Dell Precision 5280 $1629, six hard drive bays, optical drive not
>  included, but is available as an option. Windows optical media is not
>  included. But there is a single option to get it, on USB. It's not an
>  option to get it on a DVD.
>  
>  But you're saying it's standard way to install any system. Gotcha. 
It has been the standard method of installing an OS since the mid 2000s, and 
was popularized long before that. It is still the standard method of 
installing Fedora.

-- 
John M. Harris, Jr.
Splentity

[Chris Murphy]

On Sun, Dec 15, 2019 at 5:48 PM John M. Harris Jr <johnmh(a)splentity.com&gt; wrote:
>  On Sunday, December 15, 2019 5:13:22 PM MST Chris Murphy wrote:
>  > I spent about 15 minutes on this and found exactly zero systems with
>  > DVD drives, even as an option, on the Apple and Microsoft stores. None
>  > for System76. And none for HP. I did find DVD drives a custom build
>  > option on Dell's website. But even if there are some ways to dig
>  > around for systems with optical drives, it's not at all persuasive
>  > that it's common or typical or standard on prebuilt systems.
>
>  What were you looking at? I don't know about Apple, nor how that's relevant,
>  since installing a new OS on those systems invalidates the hardware warranty, 
a. It's relevant because Fedora has explicit support for Macs in the
installer; and a Mac specific release criterion.
b. The warranty claim is incorrect.

>  and I didn't even know Microsoft sold hardware. As for System76,
> I recently
>  purchased a laptop from them, their Darter Pro. It even has an option, when
>  buying the device, to include an external optical drive, because they
>  understand it's a feature that many people still rely on. 
Yes. It is an option, not standard.


>  > Dell Precision 5280 $1629, six hard drive bays, optical drive
> not
>  > included, but is available as an option. Windows optical media is not
>  > included. But there is a single option to get it, on USB. It's not an
>  > option to get it on a DVD.
>  >
>  > But you're saying it's standard way to install any system. Gotcha.
>
>  It has been the standard method of installing an OS since the mid 2000s, and
>  was popularized long before that. It is still the standard method of
>  installing Fedora. 
Your information is outdated. Apple and Microsoft haven't offered
optical media included in the box for years. For a long time now
Windows 10 OEM's offer a tool to create USB install software from a
recovery image on the drive. Not optical media.

Fedora testing can't get more than a couple people to test the optical
release criterion. These days it's typically Adam or Kamil digging
into a supply of DVDs they keep around exclusively for this test,
having no purpose for them otherwise. Overwhelmingly QA testers and
feedback is based on USB stick installations.


-- 
Chris Murphy

[John M. Harris Jr]

On Sunday, December 15, 2019 6:55:04 PM MST Chris Murphy wrote:
>  On Sun, Dec 15, 2019 at 5:48 PM John M. Harris Jr
> <johnmh(a)splentity.com&gt;
>  wrote:
>  >
>  >
>  > On Sunday, December 15, 2019 5:13:22 PM MST Chris Murphy wrote:
>  > 
>  > > I spent about 15 minutes on this and found exactly zero systems with
>  > > DVD drives, even as an option, on the Apple and Microsoft stores. None
>  > > for System76. And none for HP. I did find DVD drives a custom build
>  > > option on Dell's website. But even if there are some ways to dig
>  > > around for systems with optical drives, it's not at all persuasive
>  > > that it's common or typical or standard on prebuilt systems.
>  >
>  >
>  >
>  > What were you looking at? I don't know about Apple, nor how that's
>  > relevant, since installing a new OS on those systems invalidates the
>  > hardware warranty,
>  
>  a. It's relevant because Fedora has explicit support for Macs in the
>  installer; and a Mac specific release criterion.
>  b. The warranty claim is incorrect. 
Can you provide me with the name of the Mac specific release criterion? It's 
certainly true that Apple will not service your hardware if you've got an OS 
other than their proprietary nonsense installed.

>  > and I didn't even know Microsoft sold hardware. As for
> System76, I
>  > recently purchased a laptop from them, their Darter Pro. It even has an
>  > option, when buying the device, to include an external optical drive,
>  > because they understand it's a feature that many people still rely on.
>  
>  
>  Yes. It is an option, not standard. 
For laptops. For desktops, it is still a standard offering.


>  > It has been the standard method of installing an OS since the
> mid 2000s,
>  > and was popularized long before that. It is still the standard method of
>  > installing Fedora.
>  
>  
>  Your information is outdated. Apple and Microsoft haven't offered
>  optical media included in the box for years. For a long time now
>  Windows 10 OEM's offer a tool to create USB install software from a
>  recovery image on the drive. Not optical media. 
"included in the box" was never my claim. I don't think Apple has ever 
included ANY installation media in the box. As for Microsoft, they stopped 
including any installation media at all for OEM-installed systems, though the 
OEM might throw in an install DVD.

Another interesting anecdote: I recently build a new Windows test machine, and 
the motherboard (current generation) came with a driver CD.

>  Fedora testing can't get more than a couple people to test the
> optical
>  release criterion. These days it's typically Adam or Kamil digging
>  into a supply of DVDs they keep around exclusively for this test,
>  having no purpose for them otherwise. Overwhelmingly QA testers and
>  feedback is based on USB stick installations. 
You make it sound like disks are hard to come by. They're not.

-- 
John M. Harris, Jr.
Splentity

[Chris Murphy]

On Sun, Dec 15, 2019 at 7:37 PM John M. Harris Jr <johnmh(a)splentity.com&gt; wrote:
>  On Sunday, December 15, 2019 6:55:04 PM MST Chris Murphy wrote:
>  > On Sun, Dec 15, 2019 at 5:48 PM John M. Harris Jr <johnmh(a)splentity.com&gt;
>  > wrote:
>  > >
>  > >
>  > > On Sunday, December 15, 2019 5:13:22 PM MST Chris Murphy wrote:
>  > >
>  > > > I spent about 15 minutes on this and found exactly zero systems with
>  > > > DVD drives, even as an option, on the Apple and Microsoft stores. None
>  > > > for System76. And none for HP. I did find DVD drives a custom build
>  > > > option on Dell's website. But even if there are some ways to dig
>  > > > around for systems with optical drives, it's not at all persuasive
>  > > > that it's common or typical or standard on prebuilt systems.
>  > >
>  > >
>  > >
>  > > What were you looking at? I don't know about Apple, nor how that's
>  > > relevant, since installing a new OS on those systems invalidates the
>  > > hardware warranty,
>  >
>  > a. It's relevant because Fedora has explicit support for Macs in the
>  > installer; and a Mac specific release criterion.
>  > b. The warranty claim is incorrect.
>
>  Can you provide me with the name of the Mac specific release criterion? 
https://fedoraproject.org/wiki/Fedora_32_Final_Release_Criteria#OS_X_dual...

> It's
>  certainly true that Apple will not service your hardware if you've got an OS
>  other than their proprietary nonsense installed. 
In no way is it true, let alone certainly true.

They've explicitly supported Windows (i.e. not their proprietary
nonsense) on Macs for 13 years via Boot Camp. Software they include in
default installations of macOS. I've had Fedora on Macs for many
years, including on one sent for service and they didn't care.



>  > > and I didn't even know Microsoft sold hardware. As for System76, I
>  > > recently purchased a laptop from them, their Darter Pro. It even has an
>  > > option, when buying the device, to include an external optical drive,
>  > > because they understand it's a feature that many people still rely on.
>  >
>  >
>  > Yes. It is an option, not standard.
>
>  For laptops. For desktops, it is still a standard offering. 
Literally zero desktops I looked at today, come with optical drives
standard. Do they exist? I don't doubt they do. But they're far less
common than the standard prebuilt systems that don't have it. And it
doesn't even matter because what matters is what the community
resources dictate for this use case. And the whole impetus behind the
change proposal is lack of testers.


>  > > It has been the standard method of installing an OS since the mid 2000s,
>  > > and was popularized long before that. It is still the standard method of
>  > > installing Fedora.
>  >
>  >
>  > Your information is outdated. Apple and Microsoft haven't offered
>  > optical media included in the box for years. For a long time now
>  > Windows 10 OEM's offer a tool to create USB install software from a
>  > recovery image on the drive. Not optical media.
>
>  "included in the box" was never my claim. 
A standard method of installing, and yet not included in the box. It's
a standard way to not install.

> I don't think Apple has ever
>  included ANY installation media in the box. 
They did for many years. Floppies, CD's, DVDs.


>  > Fedora testing can't get more than a couple people to test
> the optical
>  > release criterion. These days it's typically Adam or Kamil digging
>  > into a supply of DVDs they keep around exclusively for this test,
>  > having no purpose for them otherwise. Overwhelmingly QA testers and
>  > feedback is based on USB stick installations.
>
>  You make it sound like disks are hard to come by. They're not. 
Indeed, it's the users with optical drives who are hard to come by,
especially for testing.


--
Chris Murphy

[John M. Harris Jr]

On Sunday, December 15, 2019 9:03:06 PM MST Chris Murphy wrote:
>  https://fedoraproject.org/wiki/
Fedora_32_Final_Release_Criteria#OS_X_dual_boot

Thank you, I'll see if anyone actually tests that, and see if we can get a 
Change proposal to drop that requirement if not.

>  
>  >It's certainly true that Apple will not service your hardware if you've got
>  >an OS other than their proprietary nonsense installed. 
>  > For laptops. For desktops, it is still a standard offering.
>  
>  
>  Literally zero desktops I looked at today, come with optical drives
>  standard. Do they exist? I don't doubt they do. But they're far less
>  common than the standard prebuilt systems that don't have it. And it
>  doesn't even matter because what matters is what the community
>  resources dictate for this use case. And the whole impetus behind the
>  change proposal is lack of testers. 
Again, I don't know where you looked, but that is not representative of the 
systems available today. See the examples found by myself and others earlier 
in this thread.

>  > "included in the box" was never my claim.
>  
>  
>  A standard method of installing, and yet not included in the box. It's
>  a standard way to not install. 
You completely ignored what I said, and took part of one sentence. When these 
vendors actually do include installation media at all, it's an optical disk.

>  >I don't think Apple has ever included ANY installation media
> in the box.
>  
>  They did for many years. Floppies, CD's, DVDs. 
Fair enough, I'll have to take you on your word for that, I've never purchased 
one of those devices. However, from what you've said, it seems that those 
would be optical media as well, in recent years.

>  > > Fedora testing can't get more than a couple people to
> test the optical
>  > > release criterion. These days it's typically Adam or Kamil digging
>  > > into a supply of DVDs they keep around exclusively for this test,
>  > > having no purpose for them otherwise. Overwhelmingly QA testers and
>  > > feedback is based on USB stick installations.
>  >
>  >
>  >
>  > You make it sound like disks are hard to come by. They're not.
>  
>  
>  Indeed, it's the users with optical drives who are hard to come by,
>  especially for testing. 
Is that actually the case? If so, I'd be happy to ship out an optical drive to 
anyone in need. They're incredibly inexpensive in the US, and I actually have 
a box full of them, both SATA and USB.

-- 
John M. Harris, Jr.
Splentity

[Kevin Kofler]

Chris Murphy wrote:
>  On Sun, Dec 15, 2019 at 7:37 PM John M. Harris Jr
> <johnmh(a)splentity.com&gt;
>  wrote:
> > It's certainly true that Apple will not service your hardware if you've
> > got an OS other than their proprietary nonsense installed.
>  
>  In no way is it true, let alone certainly true.
>  
>  They've explicitly supported Windows (i.e. not their proprietary
>  nonsense) on Macs for 13 years via Boot Camp. Software they include in
>  default installations of macOS. I've had Fedora on Macs for many
>  years, including on one sent for service and they didn't care. 
I guess the main difference is whether you install Fedora as a dual boot 
next to macOS (semi-supported with Boot Camp – they don't really support 
anything other than Windows, but it will not void your warranty) or whether 
you wipe macOS and install Fedora on the whole disk. I assume that the 
latter is more likely to lead to them refusing to service the machine, 
though I don't know anybody who tried that.

        Kevin Kofler

[Neal Gompa]

On Mon, Dec 16, 2019 at 6:45 AM Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote:
>  Chris Murphy wrote:
>  > On Sun, Dec 15, 2019 at 7:37 PM John M. Harris Jr <johnmh(a)splentity.com&gt;
>  > wrote:
>  >> It's certainly true that Apple will not service your hardware if you've
>  >> got an OS other than their proprietary nonsense installed.
>  >
>  > In no way is it true, let alone certainly true.
>  >
>  > They've explicitly supported Windows (i.e. not their proprietary
>  > nonsense) on Macs for 13 years via Boot Camp. Software they include in
>  > default installations of macOS. I've had Fedora on Macs for many
>  > years, including on one sent for service and they didn't care.
>
>  I guess the main difference is whether you install Fedora as a dual boot
>  next to macOS (semi-supported with Boot Camp – they don't really support
>  anything other than Windows, but it will not void your warranty) or whether
>  you wipe macOS and install Fedora on the whole disk. I assume that the
>  latter is more likely to lead to them refusing to service the machine,
>  though I don't know anybody who tried that.
>  
I did this. They service my hardware if I can prove it's a hardware
fault. It's not that different from other OEMs in that regard.

I have a MacBook that has only Fedora on it and another that has a
dual-boot with macOS. Apple is fine with both.


-- 
真実はいつも一つ！/ Always, there's only one truth!

[Kevin Kofler]

Chris Murphy wrote:
>  Three years ago I did a more involved search when looking for a new
>  laptop. Zero optical drives in new hardware. Only as external
>  accessory add-ons. 
Then you did not search well. The ThinkPad L440 my mother bought in 2016 has
an optical drive. And even now, there are still plenty of notebooks with
an optical drive:
https://geizhals.at/?cat=nb&xf=84_Blu-ray+(BD-R%2FRE)~84_Blu-ray+(BD-...

        Kevin Kofler

[Ryan Walklin]

On Mon, 16 Dec 2019, at 1:29 PM, Kevin Kofler wrote:
>  Chris Murphy wrote:
>  > Three years ago I did a more involved search when looking for a new
>  > laptop. Zero optical drives in new hardware. Only as external
>  > accessory add-ons.
>  
>  Then you did not search well. The ThinkPad L440 my mother bought in 
>  2016 has
>  an optical drive. And even now, there are still plenty of notebooks with
>  an optical drive:
>
> https://geizhals.at/?cat=nb&xf=84_Blu-ray+(BD-R%2FRE)~84_Blu-ray+(BD-...
Presumably they all also have USB ports though? I'd be more concerned about this if
there were significant amounts of hardware without USB drives that had optical drives.
I'd wager the reverse (Ultrabooks, any new laptop, NUCs etc) is the overwhelming
majority.

Not blocking for optical media install support seems fairly pragmatic to me.

Ryan

[John M. Harris Jr]

On Sunday, December 15, 2019 7:37:06 PM MST Ryan Walklin wrote: 
>  Presumably they all also have USB ports though? I'd be more
> concerned about
>  this if there were significant amounts of hardware without USB drives that
>  had optical drives. I'd wager the reverse (Ultrabooks, any new laptop, NUCs
>  etc) is the overwhelming majority.
>  
>  Not blocking for optical media install support seems fairly pragmatic to
>  me. 
Please see the examples cited earlier in the thread, of systems that cannot be 
installed from USB.

-- 
John M. Harris, Jr.
Splentity

[Chris Adams]

Once upon a time, John M. Harris Jr <johnmh(a)splentity.com&gt; said:
>  As explained earlier in this thread, DVD drives are still a standard
> offering 
>  on prebuilt systems. In fact, I just checked, and they're a standard offering 
>  on ALL of the current line Dell workstations which are RHEL certified. 
The number of Dell workstations sold from a "RHEL certified" list is
miniscule compared to the number of PC-class computers sold.  It's
possible that some "RHEL certified" requirement includes an optical
drive (I have no idea, since I didn't even know there was a "RHEL
certified" Dell, and I buy a lot of Dells).  Also, what one vendor does
for one particular class of workstation is far from representative of
all prebuilt systems.

I just checked my local Best Buy's website - of the desktop computer
models available in the store, only about 1/3 of them have an optical
drive.  Only two out of sixty notebooks have an optical drive.  I think
that's a lot more representative of where the market is going.

My home computer still has an optical drive, only because the drive
still works 10 years after I bought it (or at least it did last time I
used it, which IIRC was maybe early this year).  If I try to use the
drive and it doesn't work, I won't replace it.  However, last time I
tried to burn something (a couple of years ago?), all the blank media on
my shelf was no longer any good, so I just gave someone an old thumb
drive (cheaper than buying more media).

-- 
Chris Adams <linux(a)cmadams.net&gt;

[John M. Harris Jr]

On Sunday, December 15, 2019 7:38:43 PM MST Chris Adams wrote:
>  Once upon a time, John M. Harris Jr <johnmh(a)splentity.com&gt;
> said:
>  
>  > As explained earlier in this thread, DVD drives are still a standard
>  > offering  on prebuilt systems. In fact, I just checked, and they're a
>  > standard offering on ALL of the current line Dell workstations which are
>  > RHEL certified.
>  
>  The number of Dell workstations sold from a "RHEL certified" list is
>  miniscule compared to the number of PC-class computers sold.  It's
>  possible that some "RHEL certified" requirement includes an optical
>  drive (I have no idea, since I didn't even know there was a "RHEL
>  certified" Dell, and I buy a lot of Dells).  Also, what one vendor does
>  for one particular class of workstation is far from representative of
>  all prebuilt systems. 
To clarify, I already had that info rattling around, so I decided to throw it 
out to specify. I think "RHEL certified" just means they sent a system of that 
model to Red Hat, and one of Red Hat's engineers checked to see if everything 
has a working kernel module to support it, or paid Red Hat to throw their name 
behind it one way or another. Regardless, it's the Dell systems that are 
"designed to run GNU/Linux".

That those systems are a relatively small number is precisely why I later 
checked Walmart and Best Buy's offerings, you can read my findings on that 
earlier in the thread, but whether or not it had an optical drive seemed to 
depend heavily on the range it was in (low range systems especially seemed to 
have them).

>  I just checked my local Best Buy's website - of the desktop
> computer
>  models available in the store, only about 1/3 of them have an optical
>  drive.  Only two out of sixty notebooks have an optical drive.  I think
>  that's a lot more representative of where the market is going. 
While that may be representative of "where the market is going", it's not 
representative of where we are. Please keep in mind that we support far more 
than just the latest generation hardware. We don't support quite as much as 
Debian, but we have many users who don't have UEFI, or have early UEFI 
firmware, which doesn't support USB boot.

>  My home computer still has an optical drive, only because the drive
>  still works 10 years after I bought it (or at least it did last time I
>  used it, which IIRC was maybe early this year).  If I try to use the
>  drive and it doesn't work, I won't replace it.  However, last time I
>  tried to burn something (a couple of years ago?), all the blank media on
>  my shelf was no longer any good, so I just gave someone an old thumb
>  drive (cheaper than buying more media). 
This is a good example of what I mentioned about hardware that runs Fedora. 
Many people won't want to replace their hardware just because their OS is 
randomly throwing out compatibility for it, like we have been prone to do in 
Fedora recently. I still use an X200 Tablet as my daily driver, which is a 
Core 2 Duo system from 2008.

I also have a ThinkPad T400, which, using the default boot firmware, cannot 
boot from USB. (Though I use blobless Coreboot, where that's not an issue).

-- 
John M. Harris, Jr.
Splentity

[Chris Adams]

Once upon a time, John M. Harris Jr <johnmh(a)splentity.com&gt; said:
>  We don't support quite as much as 
>  Debian, but we have many users who don't have UEFI, or have early UEFI 
>  firmware, which doesn't support USB boot. 
There's no requirement for UEFI boot - if for some reason a system
doesn't support USB under UEFI, it is perfectly fine to install in BIOS
mode.

-- 
Chris Adams <linux(a)cmadams.net&gt;

[Chris Murphy]

On Sun, Dec 15, 2019 at 7:48 PM John M. Harris Jr <johnmh(a)splentity.com&gt; wrote:
>  While that may be representative of "where the market is going", it's not
>  representative of where we are. Please keep in mind that we support far more
>  than just the latest generation hardware. We don't support quite as much as
>  Debian, but we have many users who don't have UEFI, or have early UEFI
>  firmware, which doesn't support USB boot. 
Fedora QA has variably floated dropping the physical optical boot
criterion for at least the past two or three years. In terms of
testing, it's where we have been for a while.


>  This is a good example of what I mentioned about hardware that runs
> Fedora.
>  Many people won't want to replace their hardware just because their OS is
>  randomly throwing out compatibility for it, like we have been prone to do in
>  Fedora recently. 
Hyberbole. This is not an arbitrary proposal or process.


-- 
Chris Murphy

[John M. Harris Jr]

On Sunday, December 15, 2019 9:14:53 PM MST Chris Murphy wrote:
>  On Sun, Dec 15, 2019 at 7:48 PM John M. Harris Jr
> <johnmh(a)splentity.com&gt;
>  wrote:
>  >
>  >
>  > While that may be representative of "where the market is going", it's
> not
>  > representative of where we are. Please keep in mind that we support far
>  > more than just the latest generation hardware. We don't support quite as
>  > much as Debian, but we have many users who don't have UEFI, or have early
>  > UEFI firmware, which doesn't support USB boot.
>  
>  
>  Fedora QA has variably floated dropping the physical optical boot
>  criterion for at least the past two or three years. In terms of
>  testing, it's where we have been for a while. 
It simply is not where we are now, nor have we been "for a while".

>  > This is a good example of what I mentioned about hardware that
> runs
>  > Fedora. Many people won't want to replace their hardware just because
>  > their OS is randomly throwing out compatibility for it, like we have been
>  > prone to do in Fedora recently.
>  
>  
>  Hyberbole. This is not an arbitrary proposal or process. 
It is completely arbitrary. It works right now. Testing it requires very 
little user time, and only needs to be done after automated tests have already 
passed.

-- 
John M. Harris, Jr.
Splentity

[Chris Murphy]

On Sun, Dec 15, 2019 at 9:32 PM John M. Harris Jr <johnmh(a)splentity.com&gt; wrote:
>  On Sunday, December 15, 2019 9:14:53 PM MST Chris Murphy wrote:
>  > On Sun, Dec 15, 2019 at 7:48 PM John M. Harris Jr <johnmh(a)splentity.com&gt;
>  > wrote:
>  > >
>  > >
>  > > While that may be representative of "where the market is going",
> it's not
>  > > representative of where we are. Please keep in mind that we support far
>  > > more than just the latest generation hardware. We don't support quite as
>  > > much as Debian, but we have many users who don't have UEFI, or have early
>  > > UEFI firmware, which doesn't support USB boot.
>  >
>  >
>  > Fedora QA has variably floated dropping the physical optical boot
>  > criterion for at least the past two or three years. In terms of
>  > testing, it's where we have been for a while.
>
>  It simply is not where we are now, nor have we been "for a while". 
Based on what facts? You merely repeating yourself over and over until
people give up?

The facts are in emails and IRC conversations Adam previously cited in
this very thread. This isn't a new problem or concern. And i was
involved in those conversations. I'm not making things up and just
saying them as if I wish they were true, or as if saying things makes
them true.




>  > > This is a good example of what I mentioned about hardware that runs
>  > > Fedora. Many people won't want to replace their hardware just because
>  > > their OS is randomly throwing out compatibility for it, like we have been
>  > > prone to do in Fedora recently.
>  >
>  >
>  > Hyberbole. This is not an arbitrary proposal or process.
>
>  It is completely arbitrary. It works right now. Testing it requires very
>  little user time, and only needs to be done after automated tests have already
>  passed. 
hy·per·bo·le
/hīˈpərbəlē/
noun: hyperbole; plural noun: hyperboles
exaggerated statements or claims not meant to be taken literally.



The change proposal lays out clear subjective and objective reasoning,
and the change proposal process includes this now 70 some odd email
thread discussion, and it's not yet decided by FESCo. These are
objective processes. You calling them completely arbitrary cannot be
taken seriously. It's an unserious ridiculous characterization.



-- 
Chris Murphy

[John M. Harris Jr]

On Sunday, December 15, 2019 9:46:21 PM MST Chris Murphy wrote:
>  On Sun, Dec 15, 2019 at 9:32 PM John M. Harris Jr
> <johnmh(a)splentity.com&gt;
>  wrote:
>  >
>  >
>  > On Sunday, December 15, 2019 9:14:53 PM MST Chris Murphy wrote:
>  > 
>  > > On Sun, Dec 15, 2019 at 7:48 PM John M. Harris Jr
>  > > <johnmh(a)splentity.com&gt;
>  > > wrote:
>  > > 
>  > > >
>  > > >
>  > > >
>  > > > While that may be representative of "where the market is going",
> it's
>  > > > not
>  > > > representative of where we are. Please keep in mind that we support
>  > > > far
>  > > > more than just the latest generation hardware. We don't support quite
>  > > > as
>  > > > much as Debian, but we have many users who don't have UEFI, or have
>  > > > early
>  > > > UEFI firmware, which doesn't support USB boot.
>  > >
>  > >
>  > >
>  > >
>  > > Fedora QA has variably floated dropping the physical optical boot
>  > > criterion for at least the past two or three years. In terms of
>  > > testing, it's where we have been for a while.
>  >
>  >
>  >
>  > It simply is not where we are now, nor have we been "for a while".
>  
>  
>  Based on what facts? You merely repeating yourself over and over until
>  people give up? 
Based on the fact that this actually has been getting tested. You can claim 
otherwise, but that does not make it so. While the idea may have come up, and 
I wouldn't be aware of that, nor would it matter, it is not the case that it 
simply has become the case that it is not done.

>  The facts are in emails and IRC conversations Adam previously cited
> in
>  this very thread. This isn't a new problem or concern. And i was
>  involved in those conversations. I'm not making things up and just
>  saying them as if I wish they were true, or as if saying things makes
>  them true. 
Please see above. Additionally, there is no reason to be hostile about this.

>  > > > This is a good example of what I mentioned about
> hardware that runs
>  > > > Fedora. Many people won't want to replace their hardware just because
>  > > > their OS is randomly throwing out compatibility for it, like we have
>  > > > been
>  > > > prone to do in Fedora recently.
>  > >
>  > >
>  > >
>  > >
>  > > Hyberbole. This is not an arbitrary proposal or process.
>  >
>  >
>  >
>  > It is completely arbitrary. It works right now. Testing it requires very
>  > little user time, and only needs to be done after automated tests have
>  > already passed.
>  
>  
>  hy·per·bo·le
>  /hīˈpərbəlē/
>  noun: hyperbole; plural noun: hyperboles
>  exaggerated statements or claims not meant to be taken literally.
>  
>  
>  
>  The change proposal lays out clear subjective and objective reasoning,
>  and the change proposal process includes this now 70 some odd email
>  thread discussion, and it's not yet decided by FESCo. These are
>  objective processes. You calling them completely arbitrary cannot be
>  taken seriously. It's an unserious ridiculous characterization. 
That is, by definition, not hyperbole. It was meant to be taken seriously, and 
is an issue that needs to be addressed. This is not the only change I am 
referring to. We've been in the habit of dropping things that work, with no 
real reasons lately. For example, look at dropped x86 support, and soon we 
will be dropping Python 2. We have already had several Python 2 packages 
dropped simply because they refused to move to Python 3. This is an ongoing 
issue, where everything considered "old" is just abandoned, and it is hurting 
the user base. It is clear that is where we're headed with this Change as 
well. As soon as these tests don't need to be done before a release, they 
won't be done before a release, and we'll have a release that has broken CD/
DVD images.

-- 
John M. Harris, Jr.
Splentity

[Chris Murphy]

On Sun, Dec 15, 2019 at 11:00 PM John M. Harris Jr <johnmh(a)splentity.com&gt; wrote:
>  On Sunday, December 15, 2019 9:46:21 PM MST Chris Murphy wrote:
>  > On Sun, Dec 15, 2019 at 9:32 PM John M. Harris Jr <johnmh(a)splentity.com&gt;
>  > wrote:
>
>  > > It simply is not where we are now, nor have we been "for a while".
>  >
>  >
>  > Based on what facts? You merely repeating yourself over and over until
>  > people give up?
>
>  Based on the fact that this actually has been getting tested. You can claim
>  otherwise, but that does not make it so. While the idea may have come up, and
>  I wouldn't be aware of that, nor would it matter, it is not the case that it
>  simply has become the case that it is not done. 
First, I haven't claimed it's not getting tested.

Second, you have used a fallacy of circular reasoning. The test is
being done because it's required to be done. That the test is being
done is not a supporting fact that testing should be compulsory.

That it's usually a full time Red Hat employee doing the testing,
suggests that this criterion is not important to the community -
except apparently when it comes time to complain about dropping the
release criterion.


>  > The facts are in emails and IRC conversations Adam previously
> cited in
>  > this very thread. This isn't a new problem or concern. And i was
>  > involved in those conversations. I'm not making things up and just
>  > saying them as if I wish they were true, or as if saying things makes
>  > them true.
>
>  Please see above. Additionally, there is no reason to be hostile about this. 

Please don't waste your time, you can't make me angry.


>  > > It is completely arbitrary. It works right now. Testing it
> requires very
>  > > little user time, and only needs to be done after automated tests have
>  > > already passed.
>  >
>  >
>  > hy·per·bo·le
>  > /hīˈpərbəlē/
>  > noun: hyperbole; plural noun: hyperboles
>  > exaggerated statements or claims not meant to be taken literally.
>  >
>  >
>  >
>  > The change proposal lays out clear subjective and objective reasoning,
>  > and the change proposal process includes this now 70 some odd email
>  > thread discussion, and it's not yet decided by FESCo. These are
>  > objective processes. You calling them completely arbitrary cannot be
>  > taken seriously. It's an unserious ridiculous characterization.
>
>  That is, by definition, not hyperbole. It was meant to be taken seriously, and
>  is an issue that needs to be addressed. 
I refuse because the word you used has a meaning contrary to the facts at hand:

ar·bi·trar·y
/ˈärbəˌtrerē/
adjective: arbitrary
based on random choice or personal whim, rather than any reason or system.

This proposal is not based on anyone's personal whim. The change
process being used are not based on whim. They are part of a rational
system, one which you are mischaracterizing and prejudging the
outcome. You do this by claiming the process is random when plainly it
is not at all random. It has a structure that you merely do not like,
not that it is lacking in structure.



> This is not the only change I am
>  referring to. We've been in the habit of dropping things that work, with no
>  real reasons lately. For example, look at dropped x86 support, and soon we
>  will be dropping Python 2. We have already had several Python 2 packages
>  dropped simply because they refused to move to Python 3. This is an ongoing
>  issue, where everything considered "old" is just abandoned, and it is hurting
>  the user base. It is clear that is where we're headed with this Change as
>  well. As soon as these tests don't need to be done before a release, they
>  won't be done before a release, and we'll have a release that has broken CD/
>  DVD images. 
Why demand that people become emotionally traumatized in advance of
fantasy bugs, instead of sticking to facts and logical arguments? You
do a disservice to valid arguments in favor of retaining the release
criterion.

You are pulling off a bandaid on old wounds, making a false connection
between them and this one, and then appeal to the users as higher
authority. And it amounts to sadfishing, and doing so on their behalf
without their permission. I've told you before, I will not participate
in these attempts at emotional manipulation.

There are many hundreds of bugs fixed prior to each release, and they
are discovered and fixed by the Fedora community despite no release
criterion existing.

-- 
Chris Murphy

[Lukas Brabec]

I'm +1.

The oldest laptops I have experience with are HP 4520s and Lenovo X201i, both
from 2010, both support USB boot.

Two biggest online stores in Czechia:
- CZC.cz lists 1422 laptops without optical drive, 128 with.
- Alza.cz lists 2223 without optical drive filter, 138 with.

Every autumn, we do Fedora Installfest and I don't even think we met someone
with a laptop that doesn't support USB boot.


On Fri, Dec 13, 2019 at 12:03 PM Miro Hrončok <mhroncok(a)redhat.com&gt; wrote:
>  Juts a random idea, not very thought-out:
>
>  Could we keep optical media bugs reported by users as blocking, but not require
>  it during validation testing?
>
>
>  aka: Fedora QE would no longer have to verify optical media works.
>  but: If a tester finds an optical media  bug, it is still blocking.
>  
Well, not ideal, but if this should be the middle ground we agree on,
I'd be okay with it.


On Mon, Dec 16, 2019 at 5:36 AM John M. Harris Jr <johnmh(a)splentity.com&gt; wrote:
>  On Sunday, December 15, 2019 9:03:06 PM MST Chris Murphy wrote:
>  > https://fedoraproject.org/wiki/Fedora_32_Final_Release_Criteria#OS_X_dual...
>
>  Thank you, I'll see if anyone actually tests that, and see if we can get a
>  Change proposal to drop that requirement if not.
>  
I'm the one who usually does it [1][3][4][5], sometimes it is cmurf [2].

[1]
https://fedoraproject.org/wiki/Test_Results:Fedora_27_RC_1.2_Installation...
[2]
https://fedoraproject.org/wiki/Test_Results:Fedora_28_RC_1.1_Installation...
[3]
https://fedoraproject.org/wiki/Test_Results:Fedora_29_RC_1.2_Installation...
[4]
https://fedoraproject.org/wiki/Test_Results:Fedora_30_RC_1.1_Installation...
[5]
https://fedoraproject.org/wiki/Test_Results:Fedora_31_RC_1.3_Installation...

[John M. Harris Jr]

On Monday, December 16, 2019 1:19:55 AM MST Lukas Brabec wrote:
[snip]
>  I'm the one who usually does it [1][3][4][5], sometimes it is
> cmurf [2]. 
I saw. It's odd that Fedora supports that walled garden environment, though 
that's neither here nor there. The fact that it is actually tested is why I 
didn't follow up.

-- 
John M. Harris, Jr.
Splentity

[Solomon Peachy]

On Mon, Dec 16, 2019 at 09:19:55AM +0100, Lukas Brabec wrote:
>  The oldest laptops I have experience with are HP 4520s and Lenovo 
>  X201i, both from 2010, both support USB boot. 
I still have two AMD server motherboards deployed that don't support 
booting off of USB sticks.  But to give an idea of their age, they were 
introduced in mid-2006 and mid-2007, respectively, and saw their final 
BIOS updates in early 2009 and mid-2010, respectively.

The older motherboard should finally be retired (again) after Xmas.  But 
I'll probably stash it in case its replacement gets taken out by a 
lightning strike.  Again.

(As an aside, I discovered the newer one didn't like USB booting when 
 the F29-F30 upgrade I did twelve days ago resulted in a "No Operating 
 System Present" failure to boot, and neither of my Fedora USB sticks 
 worked.  I couldn't find any blank media around the lab, but one of my 
 colleagues had an Ubuntu DVD lying around -- with that, I was able to 
 grub2-install the system back to life...)

 - Solomon
-- 
Solomon Peachy			       pizza at shaftnet dot org
High Springs, FL                          ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.

[John M. Harris Jr]

On Monday, December 16, 2019 12:20:32 AM MST Chris Murphy wrote:
>  First, I haven't claimed it's not getting tested. 
Sorry, must have been a misunderstanding on my part.

>  Second, you have used a fallacy of circular reasoning. The test is
>  being done because it's required to be done. That the test is being
>  done is not a supporting fact that testing should be compulsory. 
That is simply not the case. The test is being done to ensure that users can 
still install Fedora using optical media.

>  That it's usually a full time Red Hat employee doing the
> testing,
>  suggests that this criterion is not important to the community -
>  except apparently when it comes time to complain about dropping the
>  release criterion. 
By "the community", you mean "developers" here? The users just use it.
All 
they care about is whether or not it works. They don't want to be involved in 
making sure it continues to work. I've already volunteered to help out in this 
thread. This is important for users.

>  > Please see above. Additionally, there is no reason to be hostile
> about
>  > this.
>  
>  
>  Please don't waste your time, you can't make me angry. 
I wouldn't attempt to do so.

>  > That is, by definition, not hyperbole. It was meant to be taken
> seriously,
>  > and is an issue that needs to be addressed.
>  
>  
>  I refuse because the word you used has a meaning contrary to the facts at
>  hand: 
 
>  ar·bi·trar·y
>  /ˈärbəˌtrerē/
>  adjective: arbitrary
>  based on random choice or personal whim, rather than any reason or system. 
This is based on random choice and personal whim, not objective reasoning. 
That there is a process does not mean that the outcome is based on anything 
more than various individuals' personal opinions.

>  This proposal is not based on anyone's personal whim. The change
>  process being used are not based on whim. They are part of a rational
>  system, one which you are mischaracterizing and prejudging the
>  outcome. You do this by claiming the process is random when plainly it
>  is not at all random. It has a structure that you merely do not like,
>  not that it is lacking in structure. 
It is not *random*, but see above.

>  >This is not the only change I am
>  >
>  > referring to. We've been in the habit of dropping things that work, with
>  > no real reasons lately. For example, look at dropped x86 support, and
>  > soon we will be dropping Python 2. We have already had several Python 2
>  > packages dropped simply because they refused to move to Python 3. This is
>  > an ongoing issue, where everything considered "old" is just abandoned,
>  > and it is hurting the user base. It is clear that is where we're headed
>  > with this Change as well. As soon as these tests don't need to be done
>  > before a release, they won't be done before a release, and we'll have a
>  > release that has broken CD/ DVD images.
>  
>  
>  Why demand that people become emotionally traumatized in advance of
>  fantasy bugs, instead of sticking to facts and logical arguments? You
>  do a disservice to valid arguments in favor of retaining the release
>  criterion. 
Emotionally traumatized? Fantasy bugs? I'm afraid that I don't know what 
you're referring to.

What I've described is precisely what WILL happen, if this Change is accepted. 
That is precisely what this sets us up for.

>  You are pulling off a bandaid on old wounds, making a false
> connection
>  between them and this one, and then appeal to the users as higher
>  authority. And it amounts to sadfishing, and doing so on their behalf
>  without their permission. I've told you before, I will not participate
>  in these attempts at emotional manipulation. 
You've mischaracterized my argument as an appeal to emotion. It is not. I'm 
stating what will happen. I'm saying this because it has happened in the past 
with several issues that started out in a similar manner.

>  There are many hundreds of bugs fixed prior to each release, and
> they
>  are discovered and fixed by the Fedora community despite no release
>  criterion existing. 
Additionally, many are not, especially not before the actual release. If this 
is not a release blocker, Fedora WILL have a release with broken CD/DVD 
install media. I suspect that would occur within two releases, though that's 
just my estimate.

-- 
John M. Harris, Jr.
Splentity

[Chris Murphy]

On Mon, Dec 16, 2019 at 1:28 AM John M. Harris Jr <johnmh(a)splentity.com&gt; wrote:

>  This is based on random choice and personal whim, not objective
> reasoning.
>  That there is a process does not mean that the outcome is based on anything
>  more than various individuals' personal opinions. 
whim
/(h)wim/
a sudden desire or change of mind, especially one that is unusual or
unexplained.

Personal preference, how people and the Project choose to prioritize,
what they choose to spend their time and effort on, is subjective. It
is neither arbitrary nor random, and not whimsical. And it's
inappropriate for you to say it is.

There is nothing sudden about this proposal. It is not unusual. It has
been laboriously explained. You just don't like what you're hearing.
And you are resorting to a variety of slander in mischaracterizing
people's decisions, through your word selection.


>  > >This is not the only change I am
>  > >
>  > > referring to. We've been in the habit of dropping things that work, with
>  > > no real reasons lately. For example, look at dropped x86 support, and
>  > > soon we will be dropping Python 2. We have already had several Python 2
>  > > packages dropped simply because they refused to move to Python 3. This is
>  > > an ongoing issue, where everything considered "old" is just
> abandoned,
>  > > and it is hurting the user base. It is clear that is where we're headed
>  > > with this Change as well. As soon as these tests don't need to be done
>  > > before a release, they won't be done before a release, and we'll have
> a
>  > > release that has broken CD/ DVD images.
>  >
>  >
>  > Why demand that people become emotionally traumatized in advance of
>  > fantasy bugs, instead of sticking to facts and logical arguments? You
>  > do a disservice to valid arguments in favor of retaining the release
>  > criterion.
>
>  Emotionally traumatized? Fantasy bugs? I'm afraid that I don't know what
>  you're referring to. 
Conjecture over bugs that do not exist, demanding they will inevitably
exist, and hyping that some large number of users will be abandoned
and injured and powerless to do anything about it, is a logical
fallacy called appeal to emotion.

The historic facts presented in this thread show this class of bug to
be rare, and identifiable by virtual device. It is baseless and
useless speculation that dropping this release criteria will result in
undiscovered and unfixed bugs. Is it possible? Sure. Is it probable
let alone certain? No. That is conjecture. Is it likely it will affect
most of the user base? No. Most of the user base does USB based
installs.


--
Chris Murphy

[Kevin Kofler]

Chris Murphy wrote:
>  There is nothing sudden about this proposal. It is not unusual. It
> has
>  been laboriously explained. You just don't like what you're hearing.
>  And you are resorting to a variety of slander in mischaracterizing
>  people's decisions, through your word selection. 
You are the one not liking what you are hearing, and hence accusing John of 
producing logical fallacies. But that itself is a logical fallacy, an ad 
hominem attack.

>  Conjecture over bugs that do not exist, demanding they will
> inevitably
>  exist, and hyping that some large number of users will be abandoned
>  and injured and powerless to do anything about it, is a logical
>  fallacy called appeal to emotion. 
There is no fallacy there. It is an undeniable fact that not considering 
something a blocker and stopping to test it (the latter being the reason for 
doing the former to begin with) WILL eventually lead to a release shipping 
with that something not fixed. That is the whole point of having blocker 
criteria to begin with.

>  The historic facts presented in this thread show this class of bug
> to
>  be rare, and identifiable by virtual device. 
No matter how rare it is, if it is not a blocker, it just has to happen to 
happen on release day (on the day of the RC compose, actually) and the 
release will ship with the bug unfixed.

(And no, "has to happen to happen" is not a typo. :-) )

>  It is baseless and useless speculation that dropping this release
> criteria
>  will result in undiscovered and unfixed bugs. Is it possible? Sure. Is it
>  probable let alone certain? No. That is conjecture. 
Your claiming the opposite is conjecture as well. There is nothing 
guaranteeing that it will not happen if you remove the one thing that is 
actually guaranteeing it now (though arbitrary criteria have already been 
put on the blocker enforcement, restricting the images it applies to, which 
(to my knowledge) have not been approved by the maintainers of the affected 
images – that needs fixing, too).

>  Is it likely it will affect most of the user base? No. Most of the
> user
>  base does USB based installs. 
True, but for something to be a blocker, it does not necessarily have to 
affect the majority of the users, just a sizable portion.

        Kevin Kofler

[Adam Williamson]

On Sun, 2019-12-15 at 22:59 -0700, John M. Harris Jr wrote:
>  This is not the only change I am referring to. We've been in the
>  habit of dropping things that work, with no real reasons lately.
>  For example, look at dropped x86 support, and soon we will be
>  dropping Python 2. We have already had several Python 2 packages
>  dropped simply because they refused to move to Python 3. This is an
>  ongoing issue, where everything considered "old" is just abandoned,
>  and it is hurting the user base. 
So, as far as I can tell, you have done no work on anything to do with
x86 support or Python 2: you have run seven package builds, ever, all
of one package in 2016.

You also have never run a Fedora validation test (or edited anything on
the wiki besides your own user space, the Council page to nominate
yourself, and the 3D Printing SIG page to add yourself).

According to your badges you've certainly made some useful
contributions to Fedora in other areas, which is great! COPR builds,
package tagging, writing articles, running meetings and so on. But you
haven't actually done any work in any of the areas you're complaining
about here, as near as I can tell.

All of the changes you refer to were changes made for the benefit of
the people doing that work (and *thus* for the good of the project as a
whole, because the resources of the people who do the work are limited
and must be allocated properly). You claim that they were done for "no
real reason", which I think is a symptom of the fact you haven't done
any of that work, which perhaps makes it harder to understand the
actual reasons.

Upstream authors are caring less and less about 32-bit support in their
code. This meant Fedora on x86 was working less and less well over
time, while at the same time sucking up considerable QA, releng and
developer time. The way Fedora is currently set up, if a package fails
to build on *any* arch, the entire build fails and is not pulled in. So
if we needed to fix a problem but the package didn't build on x86, the
problem wasn't fixed until someone figured out why not, or just blocked
the package on x86, which over time would have rendered the arch dead
by stealth. Because we do actually care about what we ship, if a
compose went on but was entirely broken on x86 we in QA and releng and
devel would try and figure out why (just as we do for ppc64le, for
instance) and that was taking up our time too. Building for x86 also
cost in terms of hardware resources, resources which could otherwise be
used for building faster on x86_64.

The first time dropping x86 support was proposed, people complained and
said they would look after it as an alternate arch, just as we have
active teams looking after ARM arches, ppc64le, s390x and so on. An x86
SIG was formed. (You didn't join it.) But it barely did anything. Folks
in QA and releng followed the process - when x86-specific issues
appeared, we flagged them up in an appropriate tracker and notified the
SIG about them. But...usually, nothing happened. People *didn't* help
fix the bugs. It all just fell on the same people again, most of the
time. These are the reasons x86 support was dropped. If you don't like
it, that's your right. But there *are* "real reasons".

Python 2 is an even simpler case: Python 2 *is no longer maintained
upstream*. The Python developers and the community members and
developers who are most passionate about Python's future desperately
want projects and users to move *off* Python 2 and *onto* Python 3.
Fedora is not a museum piece, it's a living, relatively forward-looking 
distribution. A key goal of Fedora is to *drive forward* innovation in
F/OSS. Fedora's most important job WRT the Python 3 transition is to
push the adoption of Python 3, not to prop up the existence of Python
2. That's not the job Fedora is here to do.

Again, maintaining Python 2 support is not free, and becomes
increasingly costly over time. Python is an ecosystem, bits depend on
other bits; if we hold some of it back to support Python 2 we hurt
other bits that want to move forward to Python 3. As upstreams
increasingly adopt 3 and either intentionally use features of 3 that
don't work in 2, or just stop testing their code on 2 and
unintentionally introduce 3-isms, it becomes increasingly hard to ship
new versions while still working on 2; this is work that falls on the
packagers, it is not free. Time they spend doing that is time they
don't spend otherwise improving the package or other packages.

With optical media: as I mentioned in another post, your '25 minutes'
estimate for running an optical media boot test is substantially off,
it is closer to an hour factoring in time to write the medium and run
the consistency check. That may not sound like a lot, but we frequently
produce release candidates less than 48 hours before we intend to sign
off on them. (Sometimes we have done it less than *24* hours before we
signed off). In the context of us having less than 48 hours to test the
entire release compose, some of which we spend, you know, sleeping, 2
hours (there are two images to test) of testing time is a *lot*, which
could otherwise be spent running other tests. Time has different value
at different points in the cycle: I can easily spend an hour writing
this email right now because we're not in a release crunch, in fact I
am on PTO right now so I'm spending my own time on this when I could be
playing Luigi's Mansion 3 (boy, what a sucker I am). But when the RC is
going to finish in eight hours and we have to sign off on the release
tomorrow morning, an hour suddenly seems like rather a *lot* of time.

To summarize simply: your thesis is that we are dropping things "for no
real reason" because it's easy to keep things that work working
(paraphrase, because you've replied to this thread so darn many times I
can't find the precise quote). There *is* a real reason, and it is
essentially the same real reason each time: no, it is *not* easy to
keep things that work working. It takes time and effort. We have
limited amounts of both, which we have to allocate sensibly. If we had
infinite amounts of time and effort we could develop, build and test
every feature, on every machine in the world! We don't, and we can't.
We have to pick and choose what we can cover. At *some* point, when a
Thing becomes sufficiently old that it only matters to a very small
proportion of real or potential users, we cross the line at which it
still makes sense to spend the same amount of resources on it. The
number is *never* zero, so we *always* have this argument. But it's not
wrong to say, okay, we've crossed the line.

Sometimes someone will propose that we've crossed the line when we
haven't, and usually we realize this and the proposal fails (excellent
example: the recentish "x86-64 micro-architecture update" proposal,
which met such universal raspberries it's probably not coming back for
a long time). It's possible that sometimes we get this call wrong,
we're only human. But it's wrong to suggest that decisions about what
we can and can't maintain, test and support are made for "no real
reason" or (as you suggested elsewhere) "arbitrarily". They aren't.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Andreas Tunek]

Den mån 16 dec. 2019 kl 18:42 skrev Adam Williamson <
adamwill(a)fedoraproject.org&gt;:

>  Sometimes someone will propose that we've crossed the line when we
>  haven't, and usually we realize this and the proposal fails (excellent
>  example: the recentish "x86-64 micro-architecture update" proposal,
>  which met such universal raspberries it's probably not coming back for
>  a long time). It's possible that sometimes we get this call wrong,
>  we're only human. But it's wrong to suggest that decisions about what
>  we can and can't maintain, test and support are made for "no real
>  reason" or (as you suggested elsewhere) "arbitrarily". They aren't.
>  -- 

Thank you for a very informative and detailed post!

/Andreas


>  Adam Williamson
>  Fedora QA Community Monkey
>  IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
>  http://www.happyassassin.net
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]
>

EXTERNAL: Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

[Wells, Roger K.]

On 12/16/19 1:07 PM, Andreas Tunek wrote:


Den mån 16 dec. 2019 kl 18:42 skrev Adam Williamson
<[e-mail]<mailto:[e-mail]>>:


Sometimes someone will propose that we've crossed the line when we
haven't, and usually we realize this and the proposal fails (excellent
example: the recentish "x86-64 micro-architecture update" proposal,
which met such universal raspberries it's probably not coming back for
a long time). It's possible that sometimes we get this call wrong,
we're only human. But it's wrong to suggest that decisions about what
we can and can't maintain, test and support are made for "no real
reason" or (as you suggested elsewhere) "arbitrarily". They aren't.
--

Thank you for a very informative and detailed post!

+1
/Andreas


Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
_______________________________________________
devel mailing list --
[e-mail]<mailto:[e-mail]>
To unsubscribe send an email to
[e-mail]<mailto:[e-mail]>
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]



_______________________________________________
devel mailing list --
[e-mail]<mailto:[e-mail]>
To unsubscribe send an email to
[e-mail]<mailto:[e-mail]>
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]



--
Roger Wells, P.E.
leidos
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
[e-mail]<mailto:[e-mail]>

[John M. Harris Jr]

On Monday, December 16, 2019 10:41:57 AM MST Adam Williamson wrote:
>  On Sun, 2019-12-15 at 22:59 -0700, John M. Harris Jr wrote:
>  
>  > This is not the only change I am referring to. We've been in the
>  > habit of dropping things that work, with no real reasons lately.
>  > For example, look at dropped x86 support, and soon we will be
>  > dropping Python 2. We have already had several Python 2 packages
>  > dropped simply because they refused to move to Python 3. This is an
>  > ongoing issue, where everything considered "old" is just abandoned,
>  > and it is hurting the user base.
>  
>  
>  So, as far as I can tell, you have done no work on anything to do with
>  x86 support or Python 2: you have run seven package builds, ever, all
>  of one package in 2016.
>  
>  You also have never run a Fedora validation test (or edited anything on
>  the wiki besides your own user space, the Council page to nominate
>  yourself, and the 3D Printing SIG page to add yourself).
>  
>  According to your badges you've certainly made some useful
>  contributions to Fedora in other areas, which is great! COPR builds,
>  package tagging, writing articles, running meetings and so on. But you
>  haven't actually done any work in any of the areas you're complaining
>  about here, as near as I can tell.
>  
>  All of the changes you refer to were changes made for the benefit of
>  the people doing that work (and *thus* for the good of the project as a
>  whole, because the resources of the people who do the work are limited
>  and must be allocated properly). You claim that they were done for "no
>  real reason", which I think is a symptom of the fact you haven't done
>  any of that work, which perhaps makes it harder to understand the
>  actual reasons. 
Right, my only contributions to Fedora on this account have been Mindshare 
related, and various Copr builds. I'm not currently a packager, nor am I a 
member of QA. However, that doesn't change much about my argument. It's still 
valid, especially in response to the original reasoning given for this Change. 
If the real reason is simply "The people who currently do it don't want to do 
it anymore", which is what you describe,

I've offered to take on responsibility for these tests in this thread, and I'm 
still open to that. This is still important to many users, and I'm more than 
happy to volunteer my time to support those users.

>  Upstream authors are caring less and less about 32-bit support in
> their
>  code. This meant Fedora on x86 was working less and less well over
>  time, while at the same time sucking up considerable QA, releng and
>  developer time. The way Fedora is currently set up, if a package fails
>  to build on *any* arch, the entire build fails and is not pulled in. So
>  if we needed to fix a problem but the package didn't build on x86, the
>  problem wasn't fixed until someone figured out why not, or just blocked
>  the package on x86, which over time would have rendered the arch dead
>  by stealth. Because we do actually care about what we ship, if a
>  compose went on but was entirely broken on x86 we in QA and releng and
>  devel would try and figure out why (just as we do for ppc64le, for
>  instance) and that was taking up our time too. Building for x86 also
>  cost in terms of hardware resources, resources which could otherwise be
>  used for building faster on x86_64.
>  
>  The first time dropping x86 support was proposed, people complained and
>  said they would look after it as an alternate arch, just as we have
>  active teams looking after ARM arches, ppc64le, s390x and so on. An x86
>  SIG was formed. (You didn't join it.) But it barely did anything. Folks
>  in QA and releng followed the process - when x86-specific issues
>  appeared, we flagged them up in an appropriate tracker and notified the
>  SIG about them. But...usually, nothing happened. People *didn't* help
>  fix the bugs. It all just fell on the same people again, most of the
>  time. These are the reasons x86 support was dropped. If you don't like
>  it, that's your right. But there *are* "real reasons". 
I didn't join because I didn't know about it until the followup thread to kill 
x86 entirely, at which point I did look into the work that was required, and 
just weeks later x86 was killed. There are real reasons, but it's not the 
reasons that were actually proposed. Lack of manpower is one thing, but that's 
not one of the reasons that was cited during the thread.

>  Python 2 is an even simpler case: Python 2 *is no longer maintained
>  upstream*. The Python developers and the community members and
>  developers who are most passionate about Python's future desperately
>  want projects and users to move *off* Python 2 and *onto* Python 3.
>  Fedora is not a museum piece, it's a living, relatively forward-looking 
>  distribution. A key goal of Fedora is to *drive forward* innovation in
>  F/OSS. Fedora's most important job WRT the Python 3 transition is to
>  push the adoption of Python 3, not to prop up the existence of Python
>  2. That's not the job Fedora is here to do. 
This doesn't change the fact that many Python scripts *cannot run on Python 
3*. Debian is not a museum piece either, and yet they don't just kill the old 
version. The two versions can, and do, work when both installed in parallel. 
This isn't relevant to this thread either, but several packages were simply 
dropped from Fedora because the upstream didn't have a "path forward", as it
 
was put in the FESCo ticket, to Python 3.

>  Again, maintaining Python 2 support is not free, and becomes
>  increasingly costly over time. Python is an ecosystem, bits depend on
>  other bits; if we hold some of it back to support Python 2 we hurt
>  other bits that want to move forward to Python 3. As upstreams
>  increasingly adopt 3 and either intentionally use features of 3 that
>  don't work in 2, or just stop testing their code on 2 and
>  unintentionally introduce 3-isms, it becomes increasingly hard to ship
>  new versions while still working on 2; this is work that falls on the
>  packagers, it is not free. Time they spend doing that is time they
>  don't spend otherwise improving the package or other packages. 
The two can be installed in parallel, and that's the case as it is now. Having 
one doesn't prevent you from having the other. It doesn't "hold back"
anything 
to have Python 2 present.

>  With optical media: as I mentioned in another post, your '25
> minutes'
>  estimate for running an optical media boot test is substantially off,
>  it is closer to an hour factoring in time to write the medium and run
>  the consistency check. 
It is true that I didn't account for a media check, but I did account for 
write time.

>  That may not sound like a lot, but we frequently produce release
> candidates
>  less than 48 hours before we intend to sign off on them. (Sometimes we have
>  done it less than *24* hours before we signed off). In the context of us
>  having less than 48 hours to test the entire release compose, some of which
>  we spend, you know, sleeping, 2 hours (there are two images to test) of
>  testing time is a *lot*, which could otherwise be spent running other tests.
>  Time has different value at different points in the cycle: I can easily
>  spend an hour writing this email right now because we're not in a release
>  crunch, in fact I am on PTO right now so I'm spending my own time on this
>  when I could be playing Luigi's Mansion 3 (boy, what a sucker I am). But
>  when the RC is going to finish in eight hours and we have to sign off on the
>  release tomorrow morning, an hour suddenly seems like rather a *lot* of
>  time. 
I've brought this up several times. I'm more than happy to take on the 
responsibility for this if somebody can point me in the right direction, but 
this will cause users to suffer if we don't continue to test installing from 
optical media.

>  To summarize simply: your thesis is that we are dropping things
> "for no
>  real reason" because it's easy to keep things that work working
>  (paraphrase, because you've replied to this thread so darn many times I
>  can't find the precise quote). There *is* a real reason, and it is
>  essentially the same real reason each time: no, it is *not* easy to
>  keep things that work working. It takes time and effort. We have
>  limited amounts of both, which we have to allocate sensibly. If we had
>  infinite amounts of time and effort we could develop, build and test
>  every feature, on every machine in the world! We don't, and we can't.
>  We have to pick and choose what we can cover. At *some* point, when a
>  Thing becomes sufficiently old that it only matters to a very small
>  proportion of real or potential users, we cross the line at which it
>  still makes sense to spend the same amount of resources on it. The
>  number is *never* zero, so we *always* have this argument. But it's not
>  wrong to say, okay, we've crossed the line. 
At this point in time, I'd say that line has not yet been crossed. As I've 
pointed out in this thread, by a quick look at Walmart, Best Buy and Dell's 
RHEL certified offerings, optical media is not dead, and not near it. It's 
less common than it has been, in some cases, but it is still a strong 
presence, and many systems can ONLY boot from optical media.

>  Sometimes someone will propose that we've crossed the line when
> we
>  haven't, and usually we realize this and the proposal fails (excellent
>  example: the recentish "x86-64 micro-architecture update" proposal,
>  which met such universal raspberries it's probably not coming back for
>  a long time). It's possible that sometimes we get this call wrong,
>  we're only human. But it's wrong to suggest that decisions about what
>  we can and can't maintain, test and support are made for "no real
>  reason" or (as you suggested elsewhere) "arbitrarily". They aren't.
To paraphrase what you said earlier about "old" tech, "In with the new, and

out with the old" is a fairly arbitrary way of making such decisions, 
especially with relative figures.

-- 
John M. Harris, Jr.
Splentity

[Adam Williamson]

On Mon, 2019-12-16 at 16:52 -0700, John M. Harris Jr wrote:
>  
>  Right, my only contributions to Fedora on this account have been Mindshare 
>  related, and various Copr builds. I'm not currently a packager, nor am I a 
>  member of QA. However, that doesn't change much about my argument. It's still 
>  valid, especially in response to the original reasoning given for this Change. 
>  If the real reason is simply "The people who currently do it don't want to do 
>  it anymore", which is what you describe,
>  
>  I've offered to take on responsibility for these tests in this thread, and I'm 
>  still open to that. This is still important to many users, and I'm more than 
>  happy to volunteer my time to support those users. 
If we can actually rely on you to show up and do these tests - within,
remember, sometimes a very short time frame - that'd be great. However,
we've gone through this loop before with some other criteria (we
propose dropping them, someone complains and promises to do the
testing, then doesn't actually do it in the end) enough times that we'd
be a bit cautious about this. Still, we have F32 Beta coming up quite
soon, we could potentially delay this feature and see how that goes -
see if anyone besides RH Fedora QE staff shows up to run the tests...

>  > The first time dropping x86 support was proposed, people
> complained and
>  > said they would look after it as an alternate arch, just as we have
>  > active teams looking after ARM arches, ppc64le, s390x and so on. An x86
>  > SIG was formed. (You didn't join it.) But it barely did anything. Folks
>  > in QA and releng followed the process - when x86-specific issues
>  > appeared, we flagged them up in an appropriate tracker and notified the
>  > SIG about them. But...usually, nothing happened. People *didn't* help
>  > fix the bugs. It all just fell on the same people again, most of the
>  > time. These are the reasons x86 support was dropped. If you don't like
>  > it, that's your right. But there *are* "real reasons".
>  
>  I didn't join because I didn't know about it until the followup thread to kill 
>  x86 entirely, at which point I did look into the work that was required, and 
>  just weeks later x86 was killed. There are real reasons, but it's not the 
>  reasons that were actually proposed. Lack of manpower is one thing, but that's 
>  not one of the reasons that was cited during the thread. 
It's an implied reason pretty much any time the proposal is 'stop doing
this one thing', because if we had infinite resources we'd never have
to stop doing anything. We could do *all the things*. The fact that we
have limited resources is such a basic constraint it's not always
explicitly *stated* in the Change, but it is always there.

>  > Python 2 is an even simpler case: Python 2 *is no longer
> maintained
>  > upstream*. The Python developers and the community members and
>  > developers who are most passionate about Python's future desperately
>  > want projects and users to move *off* Python 2 and *onto* Python 3.
>  > Fedora is not a museum piece, it's a living, relatively forward-looking 
>  > distribution. A key goal of Fedora is to *drive forward* innovation in
>  > F/OSS. Fedora's most important job WRT the Python 3 transition is to
>  > push the adoption of Python 3, not to prop up the existence of Python
>  > 2. That's not the job Fedora is here to do.
>  
>  This doesn't change the fact that many Python scripts *cannot run on Python 
>  3*. Debian is not a museum piece either, and yet they don't just kill the old 
>  version. The two versions can, and do, work when both installed in parallel.  
We are, uh, aware of this. They have been installed in parallel on most
Fedora installs for like a decade now.

BTW, there is another point here which you may not appreciate: Fedora
and Debian aren't really in competition. Fedora does not see its job as
being to Conquer The World and have everyone run Fedora. Fedora is
targeted at particular purposes and particular audiences. If a given
feature isn't actually driving Fedora's mission forward in any way,
it's reasonable to consider not having it any more, or at least not
making it a core part of the distribution and subject to blocking
requirements and so on. There comes a point at which we don't need to
support Python 2 for the people and use cases at which Fedora is aimed.
Will there still be people who need Python 2 for *something* at this
point? Probably! But, just as you point out, if so, they can get it
somewhere else.

Someone using Debian instead of Fedora because they need Python 2 isn't
necessarily a *problem* for Fedora. It's only a problem if it would've
served Fedora's goals and purposes for that person to be using Fedora.
If what they do isn't really a part of Fedora's goals...why should we
worry about them using Debian? Debian is a fine distribution. Nothing
wrong with it.

To put it another way...Debian and Fedora have different purposes and
different goals. Us dropping Python 2 earlier than Debian do is *things
working the right way*. We (arguably) do more than Debian to drive the
adoption and stabilization of new technologies - new stuff tends to
show up in Fedora earlier than it shows up in Debian. Debian (arguably)
does more than we do to provide long-term support for older software
and support for alternate architectures. This is a *good* thing. It's
an ecosystem that helps everyone.

>  This isn't relevant to this thread either, but several packages
> were simply 
>  dropped from Fedora because the upstream didn't have a "path forward", as
> it  
>  was put in the FESCo ticket, to Python 3. 
Yup. This was anticipated. What's the alternative? We never drop Python
2 support in order to keep software that is clearly becoming
increasingly out of date in a distribution which has "First" as one of
its core principles? This is just another angle on "it is almost never
the case that, when Fedora stops caring about something, it's a thing
that absolutely nobody and nothing wants". There has to be a cut-off.
There's probably *someone* out there who still has a Python 1
interpreter installed. And libc 5. On a 386SX. Should Fedora still work
on it?

https://docs.fedoraproject.org/en-US/project/#_first

>  > Again, maintaining Python 2 support is not free, and becomes
>  > increasingly costly over time. Python is an ecosystem, bits depend on
>  > other bits; if we hold some of it back to support Python 2 we hurt
>  > other bits that want to move forward to Python 3. As upstreams
>  > increasingly adopt 3 and either intentionally use features of 3 that
>  > don't work in 2, or just stop testing their code on 2 and
>  > unintentionally introduce 3-isms, it becomes increasingly hard to ship
>  > new versions while still working on 2; this is work that falls on the
>  > packagers, it is not free. Time they spend doing that is time they
>  > don't spend otherwise improving the package or other packages.
>  
>  The two can be installed in parallel, and that's the case as it is now. Having 
>  one doesn't prevent you from having the other. It doesn't "hold back"
> anything 
>  to have Python 2 present. 
Again, you're thinking from the perspective of the user. I'm thinking
from the perspective of the project and its maintainers. As a user
you're consuming the hard work of the people who build the project.
Supporting Python 2 *does* hold them back. That is the "work" that is
"not free" which I referred to above, points you seem to have ignored.

>  I've brought this up several times. I'm more than happy to
> take on the 
>  responsibility for this if somebody can point me in the right direction, but 
>  this will cause users to suffer if we don't continue to test installing from 
>  optical media. 
All you have to do is subscribe to the test-announce@ list and, when a
mail like this one appears:

https://lists.fedoraproject.org/archives/list/[e-mail]...

Go to the 'Installation' result page - so, for that mail, it would be
this page:

https://fedoraproject.org/wiki/Test_Results:Fedora_32_Rawhide_20191209.n....

grab the relevant ISOs (there is a download table at the top of the
page), test them according to
https://fedoraproject.org/wiki/QA:Testcase_Boot_default_install , and
enter your result in the appropriate cell in the 'Default boot and
install' table. You can do `dnf install relval` then `relval report-
results` to use a little CLI interface which will edit the page for
you, if you're not comfortable editing the wiki syntax directly (it's
quite easy, though).

It is useful to have results for all the nominated nightly composes,
but it's *critical* that we get results any time a candidate compose
appears. Those mails look similar but have a topic like "Fedora 31
Candidate RC-1.8 Available Now!".

>  > To summarize simply: your thesis is that we are dropping things
> "for no
>  > real reason" because it's easy to keep things that work working
>  > (paraphrase, because you've replied to this thread so darn many times I
>  > can't find the precise quote). There *is* a real reason, and it is
>  > essentially the same real reason each time: no, it is *not* easy to
>  > keep things that work working. It takes time and effort. We have
>  > limited amounts of both, which we have to allocate sensibly. If we had
>  > infinite amounts of time and effort we could develop, build and test
>  > every feature, on every machine in the world! We don't, and we can't.
>  > We have to pick and choose what we can cover. At *some* point, when a
>  > Thing becomes sufficiently old that it only matters to a very small
>  > proportion of real or potential users, we cross the line at which it
>  > still makes sense to spend the same amount of resources on it. The
>  > number is *never* zero, so we *always* have this argument. But it's not
>  > wrong to say, okay, we've crossed the line.
>  
>  At this point in time, I'd say that line has not yet been crossed. As I've 
>  pointed out in this thread, by a quick look at Walmart, Best Buy and Dell's 
>  RHEL certified offerings, optical media is not dead, and not near it. It's 
>  less common than it has been, in some cases, but it is still a strong 
>  presence, and many systems can ONLY boot from optical media. 
I think at this point - after you've said it about a dozen times -
everyone reading this list is aware that that's your opinion, yes.
Since this is proposed as a Change, it would be up to FESCo to decide
whether it agrees with you.
-- 
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:
>  BTW, there is another point here which you may not appreciate:
> Fedora
>  and Debian aren't really in competition. Fedora does not see its job as
>  being to Conquer The World and have everyone run Fedora. Fedora is
>  targeted at particular purposes and particular audiences. If a given
>  feature isn't actually driving Fedora's mission forward in any way,
>  it's reasonable to consider not having it any more, or at least not
>  making it a core part of the distribution and subject to blocking
>  requirements and so on. There comes a point at which we don't need to
>  support Python 2 for the people and use cases at which Fedora is aimed.
>  Will there still be people who need Python 2 for *something* at this
>  point? Probably! But, just as you point out, if so, they can get it
>  somewhere else.
>  
>  Someone using Debian instead of Fedora because they need Python 2 isn't
>  necessarily a *problem* for Fedora. It's only a problem if it would've
>  served Fedora's goals and purposes for that person to be using Fedora.
>  If what they do isn't really a part of Fedora's goals...why should we
>  worry about them using Debian? Debian is a fine distribution. Nothing
>  wrong with it.
>  
>  To put it another way...Debian and Fedora have different purposes and
>  different goals. Us dropping Python 2 earlier than Debian do is *things
>  working the right way*. We (arguably) do more than Debian to drive the
>  adoption and stabilization of new technologies - new stuff tends to
>  show up in Fedora earlier than it shows up in Debian. Debian (arguably)
>  does more than we do to provide long-term support for older software
>  and support for alternate architectures. This is a *good* thing. It's
>  an ecosystem that helps everyone. 
Except that this argument does not match actual facts. Debian is actually 
pretty aggressive at dropping legacy libraries. Debian has dropped Qt 3 
several years ago and has already started the process of dropping Qt 4. We 
still support these and even kdelibs 3 and 4 in Fedora (mostly because I am 
keeping these alive – it turns out that this is actually very little work: 
no new upstream releases to care about, just occasionally an FTBFS fix or a 
security fix to backport).

The fact that even Debian is not trying to kick out Python 2 yet shows that 
it is way too early to even consider it. Fedora is the only distribution 
insane enough to do such a radical move with draconian enforcement, even 
over the heads of the maintainers of packages depending on Python 2. (We now 
need explicit permission to depend on a package, a completely unprecedented 
and ridiculous move.)

And this also means that if you need both Qt 3 and Python 2, you are out of 
luck, because Debian refuses to carry the former (for no good reason – it 
takes me absolutely negligible work to keep Qt 3 working, I last had to 
touch it in January) and Fedora refuses to carry the latter (also for no 
good reason).

        Kevin Kofler

[Neal Gompa]

On Mon, Dec 16, 2019 at 9:37 PM Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote:
>  Adam Williamson wrote:
>  > BTW, there is another point here which you may not appreciate: Fedora
>  > and Debian aren't really in competition. Fedora does not see its job as
>  > being to Conquer The World and have everyone run Fedora. Fedora is
>  > targeted at particular purposes and particular audiences. If a given
>  > feature isn't actually driving Fedora's mission forward in any way,
>  > it's reasonable to consider not having it any more, or at least not
>  > making it a core part of the distribution and subject to blocking
>  > requirements and so on. There comes a point at which we don't need to
>  > support Python 2 for the people and use cases at which Fedora is aimed.
>  > Will there still be people who need Python 2 for *something* at this
>  > point? Probably! But, just as you point out, if so, they can get it
>  > somewhere else.
>  >
>  > Someone using Debian instead of Fedora because they need Python 2 isn't
>  > necessarily a *problem* for Fedora. It's only a problem if it would've
>  > served Fedora's goals and purposes for that person to be using Fedora.
>  > If what they do isn't really a part of Fedora's goals...why should we
>  > worry about them using Debian? Debian is a fine distribution. Nothing
>  > wrong with it.
>  >
>  > To put it another way...Debian and Fedora have different purposes and
>  > different goals. Us dropping Python 2 earlier than Debian do is *things
>  > working the right way*. We (arguably) do more than Debian to drive the
>  > adoption and stabilization of new technologies - new stuff tends to
>  > show up in Fedora earlier than it shows up in Debian. Debian (arguably)
>  > does more than we do to provide long-term support for older software
>  > and support for alternate architectures. This is a *good* thing. It's
>  > an ecosystem that helps everyone.
>
>  Except that this argument does not match actual facts. Debian is actually
>  pretty aggressive at dropping legacy libraries. Debian has dropped Qt 3
>  several years ago and has already started the process of dropping Qt 4. We
>  still support these and even kdelibs 3 and 4 in Fedora (mostly because I am
>  keeping these alive – it turns out that this is actually very little work:
>  no new upstream releases to care about, just occasionally an FTBFS fix or a
>  security fix to backport).
>
>  The fact that even Debian is not trying to kick out Python 2 yet shows that
>  it is way too early to even consider it. Fedora is the only distribution
>  insane enough to do such a radical move with draconian enforcement, even
>  over the heads of the maintainers of packages depending on Python 2. (We now
>  need explicit permission to depend on a package, a completely unprecedented
>  and ridiculous move.)
>  
You've been saying this a lot lately, and this isn't actually backed
up by reality.

Debian *is* dropping Python 2 support. As of right now, they are
working on transitioning to making providing Python 2 packages as
a bug of serious severity. This means that packages in unstable providing
Python 2 modules will no longer automatically transition to testing
and need exceptions to do so. In addition, there's discussion underway
to make it rc-blocking as well, meaning that packages may not be able
to transition into testing *without* removing Python 2 support
*first*.

While not all of this is implemented just yet in Debian (everything
moves glacially slow there...), it *is* happening. Debian definitely
does not want to make another release with Python 2 in the
distribution. Ubuntu has already decided to filter out all Python 2
packages from Ubuntu 20.04 LTS, so it's not going to be there either.

And you know what? This was all made possible by Fedora's work over
the last several releases to port lots of software to Python 3,
aggressively migrate to Python 3 by default, and now finally dropping
Python 2 stuff over the last three releases.

We may keep the python27 interpreter package for a while, but I don't
expect us to keep much beyond that.



--
真実はいつも一つ！/ Always, there's only one truth!

[Miro Hrončok]

On 17. 12. 19 3:54, Neal Gompa wrote:
>  On Mon, Dec 16, 2019 at 9:37 PM Kevin Kofler
> <kevin.kofler(a)chello.at&gt; wrote:
> >
> > Adam Williamson wrote:
> >> BTW, there is another point here which you may not appreciate: Fedora
> >> and Debian aren't really in competition. Fedora does not see its job as
> >> being to Conquer The World and have everyone run Fedora. Fedora is
> >> targeted at particular purposes and particular audiences. If a given
> >> feature isn't actually driving Fedora's mission forward in any way,
> >> it's reasonable to consider not having it any more, or at least not
> >> making it a core part of the distribution and subject to blocking
> >> requirements and so on. There comes a point at which we don't need to
> >> support Python 2 for the people and use cases at which Fedora is aimed.
> >> Will there still be people who need Python 2 for *something* at this
> >> point? Probably! But, just as you point out, if so, they can get it
> >> somewhere else.
> >>
> >> Someone using Debian instead of Fedora because they need Python 2 isn't
> >> necessarily a *problem* for Fedora. It's only a problem if it would've
> >> served Fedora's goals and purposes for that person to be using Fedora.
> >> If what they do isn't really a part of Fedora's goals...why should we
> >> worry about them using Debian? Debian is a fine distribution. Nothing
> >> wrong with it.
> >>
> >> To put it another way...Debian and Fedora have different purposes and
> >> different goals. Us dropping Python 2 earlier than Debian do is *things
> >> working the right way*. We (arguably) do more than Debian to drive the
> >> adoption and stabilization of new technologies - new stuff tends to
> >> show up in Fedora earlier than it shows up in Debian. Debian (arguably)
> >> does more than we do to provide long-term support for older software
> >> and support for alternate architectures. This is a *good* thing. It's
> >> an ecosystem that helps everyone.
> >
> > Except that this argument does not match actual facts. Debian is actually
> > pretty aggressive at dropping legacy libraries. Debian has dropped Qt 3
> > several years ago and has already started the process of dropping Qt 4. We
> > still support these and even kdelibs 3 and 4 in Fedora (mostly because I am
> > keeping these alive – it turns out that this is actually very little work:
> > no new upstream releases to care about, just occasionally an FTBFS fix or a
> > security fix to backport).
> >
> > The fact that even Debian is not trying to kick out Python 2 yet shows that
> > it is way too early to even consider it. Fedora is the only distribution
> > insane enough to do such a radical move with draconian enforcement, even
> > over the heads of the maintainers of packages depending on Python 2. (We now
> > need explicit permission to depend on a package, a completely unprecedented
> > and ridiculous move.)
> >
>  
>  You've been saying this a lot lately, and this isn't actually backed
>  up by reality.
>  
>  Debian *is* dropping Python 2 support. As of right now, they are
>  working on transitioning to making providing Python 2 packages as
>  a bug of serious severity. This means that packages in unstable providing
>  Python 2 modules will no longer automatically transition to testing
>  and need exceptions to do so. In addition, there's discussion underway
>  to make it rc-blocking as well, meaning that packages may not be able
>  to transition into testing *without* removing Python 2 support
>  *first*.
>  
>  While not all of this is implemented just yet in Debian (everything
>  moves glacially slow there...), it *is* happening. Debian definitely
>  does not want to make another release with Python 2 in the
>  distribution. Ubuntu has already decided to filter out all Python 2
>  packages from Ubuntu 20.04 LTS, so it's not going to be there either.
>  
>  And you know what? This was all made possible by Fedora's work over
>  the last several releases to port lots of software to Python 3,
>  aggressively migrate to Python 3 by default, and now finally dropping
>  Python 2 stuff over the last three releases.
>  
>  We may keep the python27 interpreter package for a while, but I don't
>  expect us to keep much beyond that. 
Thank You Neal, I was about to say pretty much the same but I could have not 
done it better.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Peter Pentchev]

On Mon, Dec 16, 2019 at 09:54:49PM -0500, Neal Gompa wrote:
>  On Mon, Dec 16, 2019 at 9:37 PM Kevin Kofler
> <kevin.kofler(a)chello.at&gt; wrote:
>  >
>  > Adam Williamson wrote:
>  > > BTW, there is another point here which you may not appreciate: Fedora
>  > > and Debian aren't really in competition. Fedora does not see its job as
>  > > being to Conquer The World and have everyone run Fedora. Fedora is
>  > > targeted at particular purposes and particular audiences. If a given
>  > > feature isn't actually driving Fedora's mission forward in any way,
>  > > it's reasonable to consider not having it any more, or at least not
>  > > making it a core part of the distribution and subject to blocking
>  > > requirements and so on. There comes a point at which we don't need to
>  > > support Python 2 for the people and use cases at which Fedora is aimed.
>  > > Will there still be people who need Python 2 for *something* at this
>  > > point? Probably! But, just as you point out, if so, they can get it
>  > > somewhere else.
>  > >
>  > > Someone using Debian instead of Fedora because they need Python 2 isn't
>  > > necessarily a *problem* for Fedora. It's only a problem if it would've
>  > > served Fedora's goals and purposes for that person to be using Fedora.
>  > > If what they do isn't really a part of Fedora's goals...why should we
>  > > worry about them using Debian? Debian is a fine distribution. Nothing
>  > > wrong with it.
>  > >
>  > > To put it another way...Debian and Fedora have different purposes and
>  > > different goals. Us dropping Python 2 earlier than Debian do is *things
>  > > working the right way*. We (arguably) do more than Debian to drive the
>  > > adoption and stabilization of new technologies - new stuff tends to
>  > > show up in Fedora earlier than it shows up in Debian. Debian (arguably)
>  > > does more than we do to provide long-term support for older software
>  > > and support for alternate architectures. This is a *good* thing. It's
>  > > an ecosystem that helps everyone.
>  >
>  > Except that this argument does not match actual facts. Debian is actually
>  > pretty aggressive at dropping legacy libraries. Debian has dropped Qt 3
>  > several years ago and has already started the process of dropping Qt 4. We
>  > still support these and even kdelibs 3 and 4 in Fedora (mostly because I am
>  > keeping these alive – it turns out that this is actually very little work:
>  > no new upstream releases to care about, just occasionally an FTBFS fix or a
>  > security fix to backport).
>  >
>  > The fact that even Debian is not trying to kick out Python 2 yet shows that
>  > it is way too early to even consider it. Fedora is the only distribution
>  > insane enough to do such a radical move with draconian enforcement, even
>  > over the heads of the maintainers of packages depending on Python 2. (We now
>  > need explicit permission to depend on a package, a completely unprecedented
>  > and ridiculous move.)
>  >
>  
>  You've been saying this a lot lately, and this isn't actually backed
>  up by reality.
>  
>  Debian *is* dropping Python 2 support. As of right now, they are
>  working on transitioning to making providing Python 2 packages as
>  a bug of serious severity. This means that packages in unstable providing
>  Python 2 modules will no longer automatically transition to testing
>  and need exceptions to do so. In addition, there's discussion underway
>  to make it rc-blocking as well, meaning that packages may not be able
>  to transition into testing *without* removing Python 2 support
>  *first*.
>  
>  While not all of this is implemented just yet in Debian (everything
>  moves glacially slow there...), it *is* happening. Debian definitely
>  does not want to make another release with Python 2 in the
>  distribution. Ubuntu has already decided to filter out all Python 2
>  packages from Ubuntu 20.04 LTS, so it's not going to be there either.
>  
>  And you know what? This was all made possible by Fedora's work over
>  the last several releases to port lots of software to Python 3,
>  aggressively migrate to Python 3 by default, and now finally dropping
>  Python 2 stuff over the last three releases.
>  
>  We may keep the python27 interpreter package for a while, but I don't
>  expect us to keep much beyond that. 
Right. Must learn to read before posting. Must learn to read the whole
thread before posting.

As a (relatively recent) Debian Developer, I have to say I agree with
everything that Neal said, including the parts about Fedora's work!

G'luck,
Peter

-- 
Peter Pentchev  roam(a){ringlet.net,debian.org,FreeBSD.org} pp(a)storpool.com
PGP key:        http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13

[Kevin Kofler]

Neal Gompa wrote:
>  You've been saying this a lot lately, and this isn't actually
> backed
>  up by reality.
>  
>  Debian *is* dropping Python 2 support. 
It was Adam Williamson who claimed that Debian would still support Python 2. 
I neglected to verify that claim, sorry for that.

But this means that his argument that users who need Python 2 should just 
switch to Debian is null and void.

So far, Fedora has always been one of the few distributions willing to ship 
legacy compatibility libraries to keep software working. See GTK+ 1, Qt 3, 
etc. (Some of it, such as Qt 3, was partly my own work, some of it, such as 
GTK+ 1, has been entirely done by other volunteers.) With the Python 2 
policy, and also with the package deprecation process that was introduced 
recently, Fedora is making a radical U-turn, which will make it much less 
useful for end users. And there is no real alternative to switch to. Debian 
is clearly not one.

Maintainers need to realize that there is lots of niche software out there 
that is effectively unmaintained (and thus will never get ported to Python 3 
etc.), but that works, fulfills some task, and has no more recent 
alternative available. What should people relying on such software do?

        Kevin Kofler

[Peter Pentchev]

On Tue, Dec 17, 2019 at 01:04:43PM +0100, Kevin Kofler wrote:
>  Neal Gompa wrote:
>  > You've been saying this a lot lately, and this isn't actually backed
>  > up by reality.
>  > 
>  > Debian *is* dropping Python 2 support.
>  
>  It was Adam Williamson who claimed that Debian would still support Python 2. 
>  I neglected to verify that claim, sorry for that.
>  
>  But this means that his argument that users who need Python 2 should just 
>  switch to Debian is null and void.
>  
>  So far, Fedora has always been one of the few distributions willing to ship 
>  legacy compatibility libraries to keep software working. See GTK+ 1, Qt 3, 
>  etc. (Some of it, such as Qt 3, was partly my own work, some of it, such as 
>  GTK+ 1, has been entirely done by other volunteers.) With the Python 2 
>  policy, and also with the package deprecation process that was introduced 
>  recently, Fedora is making a radical U-turn, which will make it much less 
>  useful for end users. And there is no real alternative to switch to. Debian 
>  is clearly not one.
>  
>  Maintainers need to realize that there is lots of niche software out there 
>  that is effectively unmaintained (and thus will never get ported to Python 3 
>  etc.), but that works, fulfills some task, and has no more recent 
>  alternative available. What should people relying on such software do? 
Either figure out a way to get people to maintain the software, or
figure out a way to get people to develop a replacement, or keep using
the unmaintained software on equally unmaintained older versions of
operating systems that it will run on.

Sorry for the bluntness, but, well...

G'luck,
Peter

-- 
Peter Pentchev  roam(a){ringlet.net,debian.org,FreeBSD.org} pp(a)storpool.com
PGP key:        http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13

[Kamil Paral]

On Tue, Dec 17, 2019 at 1:13 PM Peter Pentchev <roam(a)ringlet.net&gt; wrote:

>  > Maintainers need to realize that there is lots of niche software
> out
>  there
>  > that is effectively unmaintained (and thus will never get ported to
>  Python 3
>  > etc.), but that works, fulfills some task, and has no more recent
>  > alternative available. What should people relying on such software do?
>
>  Either figure out a way to get people to maintain the software, or
>  figure out a way to get people to develop a replacement, or keep using
>  the unmaintained software on equally unmaintained older versions of
>  operating systems that it will run on.
>  
Peter started a separate thread for Python 2 discussion (thank you!), so
EVERYONE who wishes to discuss Python 2, please move that discussion into
that thread and out of this topic. Thank you.

[Adam Williamson]

On Tue, 2019-12-17 at 13:04 +0100, Kevin Kofler wrote:
>  Neal Gompa wrote:
>  > You've been saying this a lot lately, and this isn't actually backed
>  > up by reality.
>  > 
>  > Debian *is* dropping Python 2 support.
>  
>  It was Adam Williamson who claimed that Debian would still support Python 2. 
>  I neglected to verify that claim, sorry for that. 
Actually I didn't. I said "Someone using Debian instead of Fedora
because they need Python 2..." and "Us dropping Python 2 earlier than
Debian do". Both of those just refer to Fedora dropping Python 3
support *earlier than* Debian does. Which is certainly what's going to
happen, as our last release with Python 2 will go EOL long before
Debian's last release with Python 2 does.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Kamil Paral]

On Tue, Dec 17, 2019 at 5:19 PM Adam Williamson <adamwill(a)fedoraproject.org&gt;
wrote:

>  On Tue, 2019-12-17 at 13:04 +0100, Kevin Kofler wrote:
>  > Neal Gompa wrote:
>  > > You've been saying this a lot lately, and this isn't actually backed
>  > > up by reality.
>  > >
>  > > Debian *is* dropping Python 2 support.
>  >
>  > It was Adam Williamson who claimed that Debian would still support
>  Python 2.
>  > I neglected to verify that claim, sorry for that.
>
>  Actually I didn't. I said "Someone using Debian instead of Fedora
>  because they need Python 2..." and "Us dropping Python 2 earlier than
>  Debian do". Both of those just refer to Fedora dropping Python 3
>  support *earlier than* Debian does. Which is certainly what's going to
>  happen, as our last release with Python 2 will go EOL long before
>  Debian's last release with Python 2 does.
>  
Adam, it's not helping when I ask everybody to move off-topic conversation
to separate threads, but you keep replying to the original one :)

[John M. Harris Jr]

On Monday, December 16, 2019 6:30:14 PM MST Adam Williamson wrote:
>  Yup. This was anticipated. What's the alternative? We never drop
> Python
>  2 support in order to keep software that is clearly becoming
>  increasingly out of date in a distribution which has "First" as one of
>  its core principles? This is just another angle on "it is almost never
>  the case that, when Fedora stops caring about something, it's a thing
>  that absolutely nobody and nothing wants". There has to be a cut-off.
>  There's probably *someone* out there who still has a Python 1
>  interpreter installed. And libc 5. On a 386SX. Should Fedora still work
>  on it? 
In my opinion, this should be supported, even if stuck at the last version 
packaged, until that version no longer works. If nobody wants to put in the 
work to make the package work at that point, THEN is the time to drop it, in 
my opinion.

-- 
John M. Harris, Jr.
Splentity

[John M. Harris Jr]

On Monday, December 16, 2019 6:30:14 PM MST Adam Williamson wrote:
>  All you have to do is subscribe to the test-announce@ list and, when
> a
>  mail like this one appears:
>  
>  https://lists.fedoraproject.org/archives/list/[e-mail]
>  ect.org/thread/TU5YRBVDQIKUHLZCYVRUMFFPENHL3CPZ/
>  
>  Go to the 'Installation' result page - so, for that mail, it would be
>  this page:
>  
>  https://fedoraproject.org/wiki/Test_Results:Fedora_32_Rawhide_20191209.n.0_I
>  nstallation
>  
>  grab the relevant ISOs (there is a download table at the top of the
>  page), test them according to
>  https://fedoraproject.org/wiki/QA:Testcase_Boot_default_install , and
>  enter your result in the appropriate cell in the 'Default boot and
>  install' table. You can do `dnf install relval` then `relval report-
>  results` to use a little CLI interface which will edit the page for
>  you, if you're not comfortable editing the wiki syntax directly (it's
>  quite easy, though).
>  
>  It is useful to have results for all the nominated nightly composes,
>  but it's *critical* that we get results any time a candidate compose
>  appears. Those mails look similar but have a topic like "Fedora 31
>  Candidate RC-1.8 Available Now!". 
Sounds good, I'll subscribe to that list when I get to work tomorrow. I'll set 
aside a T400 running the standard boot firmware to test optical media on. Past 
that, I'll pick out some system that supports UEFI to test UEFI optical boot 
on. While I may not be able to test *every* version, I'll make sure to test 
every RC, and every nominated nightly compose I can.

-- 
John M. Harris, Jr.
Splentity

[Kamil Paral]

On Tue, Dec 17, 2019 at 4:17 AM John M. Harris Jr <johnmh(a)splentity.com&gt;
wrote:

>  Sounds good, I'll subscribe to that list when I get to work
> tomorrow. I'll
>  set
>  aside a T400 running the standard boot firmware to test optical media on.
>  Past
>  that, I'll pick out some system that supports UEFI to test UEFI optical
>  boot
>  on. While I may not be able to test *every* version, I'll make sure to
>  test
>  every RC, and every nominated nightly compose I can.
>  
Great. That will definitely help.

[Frantisek Zatloukal]

On Tue, Dec 17, 2019 at 2:31 AM Adam Williamson <adamwill(a)fedoraproject.org&gt;
wrote:

>  Still, we have F32 Beta coming up quite
>  soon, we could potentially delay this feature and see how that goes -
>  see if anyone besides RH Fedora QE staff shows up to run the tests...
>  
We still can have optical media as non blocking, that doesn't prevent
anybody testing it and filling wiki page with results.

[John M. Harris Jr]

On Tuesday, December 17, 2019 1:09:17 AM MST Frantisek Zatloukal wrote:
>  On Tue, Dec 17, 2019 at 2:31 AM Adam Williamson
> <adamwill(a)fedoraproject.org&gt;
>  wrote:
>  > Still, we have F32 Beta coming up quite
>  > soon, we could potentially delay this feature and see how that goes -
>  > see if anyone besides RH Fedora QE staff shows up to run the tests...
>  
>  We still can have optical media as non blocking, that doesn't prevent
>  anybody testing it and filling wiki page with results. 
But it would mean that Fedora would potentially release with optical boot 
broken.

-- 
John M. Harris, Jr.
Splentity

[Frantisek Zatloukal]

On Wed, Dec 18, 2019 at 1:37 AM John M. Harris Jr <johnmh(a)splentity.com&gt;
wrote:

>  But it would mean that Fedora would potentially release with optical
> boot
>  broken. 

Yes, and it was said about a million times in all threads regarding this
change proposal.  There is no need to say it again and again.

Yes, it can result (probably won't in the foreseeable future) in broken
optical media boot. And yes, I still stand for this change proposal.

[Kamil Paral]

On Tue, Dec 17, 2019 at 2:31 AM Adam Williamson <adamwill(a)fedoraproject.org&gt;
wrote:

>  On Mon, 2019-12-16 at 16:52 -0700, John M. Harris Jr wrote:
>  > I've offered to take on responsibility for these tests in this thread,
>  and I'm
>  > still open to that. This is still important to many users, and I'm more
>  than
>  > happy to volunteer my time to support those users.
>
>  If we can actually rely on you to show up and do these tests - within,
>  remember, sometimes a very short time frame - that'd be great. However,
>  we've gone through this loop before with some other criteria (we
>  propose dropping them, someone complains and promises to do the
>  testing, then doesn't actually do it in the end) enough times that we'd
>  be a bit cautious about this. Still, we have F32 Beta coming up quite
>  soon, we could potentially delay this feature and see how that goes -
>  see if anyone besides RH Fedora QE staff shows up to run the tests...
>  
I think having community help with optical testing shouldn't really affect
the outcome of the proposal. We claim that the importance of optical media
has diminished and it's now below the threshold for granting it a
release-blocking status. That's not really affected by whom executes the
tests. I'm really interested to know what the community and FESCo thinks
about this, and that's why this proposal is useful.
If we keep blocking on optical media, we'll need to keep verifying it, and
of course any community help will be very appreciated. If we stop blocking
on it, we'll be able to run the test just optionally when we have spare
time, and of course any community help will still be very appreciated.

[Adam Williamson]

On Tue, 2019-12-17 at 10:43 +0100, Kamil Paral wrote:
>  On Tue, Dec 17, 2019 at 2:31 AM Adam Williamson
> <adamwill(a)fedoraproject.org&gt;
>  wrote:
>  
>  > On Mon, 2019-12-16 at 16:52 -0700, John M. Harris Jr wrote:
>  > > I've offered to take on responsibility for these tests in this thread,
>  > and I'm
>  > > still open to that. This is still important to many users, and I'm more
>  > than
>  > > happy to volunteer my time to support those users.
>  > 
>  > If we can actually rely on you to show up and do these tests - within,
>  > remember, sometimes a very short time frame - that'd be great. However,
>  > we've gone through this loop before with some other criteria (we
>  > propose dropping them, someone complains and promises to do the
>  > testing, then doesn't actually do it in the end) enough times that we'd
>  > be a bit cautious about this. Still, we have F32 Beta coming up quite
>  > soon, we could potentially delay this feature and see how that goes -
>  > see if anyone besides RH Fedora QE staff shows up to run the tests...
>  > 
>  
>  I think having community help with optical testing shouldn't really affect
>  the outcome of the proposal. We claim that the importance of optical media
>  has diminished and it's now below the threshold for granting it a
>  release-blocking status. That's not really affected by whom executes the
>  tests. 
To me it is, in a weird way: I tend to view the presence of someone
who's willing to actually *do* something as a proxy for there being
others who care about it. For instance on the 32-bit x86 topic - if the
x86 SIG had *worked* and we'd had one or two people who really cared
about it show up to do the work, like we have for ARM or ppc64, I'd
have been more inclined to believe there were more people out there who
really needed to run Fedora on 32-bit x86.

So if the question is "do people really want Fedora on physical optical
disc?", I'm more likely to believe the answer is 'yes' if one or two of
them shows up to actually test it...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Ralf Corsepius]

On 12/17/19 5:14 PM, Adam Williamson wrote:
>  On Tue, 2019-12-17 at 10:43 +0100, Kamil Paral wrote:
> > On Tue, Dec 17, 2019 at 2:31 AM Adam Williamson <adamwill(a)fedoraproject.org&gt;
> > wrote:
> >
> >> On Mon, 2019-12-16 at 16:52 -0700, John M. Harris Jr wrote:
> >>> I've offered to take on responsibility for these tests in this thread,
> >> and I'm
> >>> still open to that. This is still important to many users, and I'm more
> >> than
> >>> happy to volunteer my time to support those users.
> >>
> >> If we can actually rely on you to show up and do these tests - within,
> >> remember, sometimes a very short time frame - that'd be great. However,
> >> we've gone through this loop before with some other criteria (we
> >> propose dropping them, someone complains and promises to do the
> >> testing, then doesn't actually do it in the end) enough times that we'd
> >> be a bit cautious about this. Still, we have F32 Beta coming up quite
> >> soon, we could potentially delay this feature and see how that goes -
> >> see if anyone besides RH Fedora QE staff shows up to run the tests...
> >>
> >
> > I think having community help with optical testing shouldn't really affect
> > the outcome of the proposal. We claim that the importance of optical media
> > has diminished and it's now below the threshold for granting it a
> > release-blocking status. That's not really affected by whom executes the
> > tests.
>  
>  To me it is, in a weird way: I tend to view the presence of someone
>  who's willing to actually *do* something as a proxy for there being
>  others who care about it. For instance on the 32-bit x86 topic - if the
>  x86 SIG had *worked* and we'd had one or two people who really cared
>  about it show up to do the work, like we have for ARM or ppc64, I'd
>  have been more inclined to believe there were more people out there who
>  really needed to run Fedora on 32-bit x86. 
 From my perspective, you are twisting reality. The 32-bit x86 sig never 
had a chance, because it was clear to everybody involved, RHAT wanted to 
kill it and because everybody @RH proactively worked against any attempt 
  to support it.

>  So if the question is "do people really want Fedora on physical
> optical
>  disc?", I'm more likely to believe the answer is 'yes' if one or two of
>  them shows up to actually test it... 
I am definitely for "keeping optical
media". But because of the lessons 
learnt from how RHAT behaved in the i386-shoting and on the modules 
crap, I am not expecting RHAT nor FESCO to listen nor to care.

Now think about, why Fedora is loosing users.

Ralf

[Adam Williamson]

On Tue, 2019-12-17 at 20:53 +0100, Ralf Corsepius wrote:
>  
>  > To me it is, in a weird way: I tend to view the presence of someone
>  > who's willing to actually *do* something as a proxy for there being
>  > others who care about it. For instance on the 32-bit x86 topic - if the
>  > x86 SIG had *worked* and we'd had one or two people who really cared
>  > about it show up to do the work, like we have for ARM or ppc64, I'd
>  > have been more inclined to believe there were more people out there who
>  > really needed to run Fedora on 32-bit x86.
>  
>   From my perspective, you are twisting reality. The 32-bit x86 sig never 
>  had a chance, because it was clear to everybody involved, RHAT wanted to 
>  kill it and because everybody @RH proactively worked against any attempt 
>    to support it. 
Um. So those times I found bugs specific to 32-bit x86 and mailed the
list about them, that was me proactively working against any attempt to
support it? That's funny, that's not how it felt at the time.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

Debian and Python 2 [Was: Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion]

[Peter Pentchev]

On Mon, Dec 16, 2019 at 05:30:14PM -0800, Adam Williamson wrote:
>  On Mon, 2019-12-16 at 16:52 -0700, John M. Harris Jr wrote:
[snip]
>  > This doesn't change the fact that many Python scripts
> *cannot run on Python 
>  > 3*. Debian is not a museum piece either, and yet they don't just kill the old 
>  > version. The two versions can, and do, work when both installed in parallel. 
>  
>  We are, uh, aware of this. They have been installed in parallel on most
>  Fedora installs for like a decade now.
>  
>  BTW, there is another point here which you may not appreciate: Fedora
>  and Debian aren't really in competition. Fedora does not see its job as
>  being to Conquer The World and have everyone run Fedora. Fedora is
>  targeted at particular purposes and particular audiences. If a given
>  feature isn't actually driving Fedora's mission forward in any way,
>  it's reasonable to consider not having it any more, or at least not
>  making it a core part of the distribution and subject to blocking
>  requirements and so on. There comes a point at which we don't need to
>  support Python 2 for the people and use cases at which Fedora is aimed.
>  Will there still be people who need Python 2 for *something* at this
>  point? Probably! But, just as you point out, if so, they can get it
>  somewhere else.
>  
>  Someone using Debian instead of Fedora because they need Python 2 isn't
>  necessarily a *problem* for Fedora. It's only a problem if it would've
>  served Fedora's goals and purposes for that person to be using Fedora.
>  If what they do isn't really a part of Fedora's goals...why should we
>  worry about them using Debian? Debian is a fine distribution. Nothing
>  wrong with it.
>  
>  To put it another way...Debian and Fedora have different purposes and
>  different goals. Us dropping Python 2 earlier than Debian do is *things
>  working the right way*. We (arguably) do more than Debian to drive the
>  adoption and stabilization of new technologies - new stuff tends to
>  show up in Fedora earlier than it shows up in Debian. Debian (arguably)
>  does more than we do to provide long-term support for older software
>  and support for alternate architectures. This is a *good* thing. It's
>  an ecosystem that helps everyone. 
Also, well, Debian *is* dropping Python 2 in its next release:
- https://lists.debian.org/debian-python/2019/07/msg00080.html
- https://wiki.debian.org/Python/2Removal

Many Python 2 modules have been dropped already, many others will be
dropped in the coming months. Yes, there are complications such as
Calibre, but this is, for all intents and purposes, practically
a release goal now.

Sorry for contributing to the more-and-more-off-topic rant, but I just
felt the need to point this out, since I've seen it mentioned a couple
of times recently.

G'luck,
Peter

-- 
Peter Pentchev  roam(a){ringlet.net,debian.org,FreeBSD.org} pp(a)storpool.com
PGP key:        http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13

[Chris Adams]

Once upon a time, John M. Harris Jr <johnmh(a)splentity.com&gt; said:
>  In fact, I just checked, and they're a standard offering 
>  on ALL of the current line Dell workstations which are RHEL certified. 
Also, this is not true.  I found the Dell Linux workstation page, and no
models on that page include an optical drive in the standard
configurations.
-- 
Chris Adams <linux(a)cmadams.net&gt;

[Justin W. Flory]

>  Miro Hrončok wrote:
>  
>  The devel list is the first place where developers gather feedback. The idea to 
>  reach a committee (whether FESCo or Mindshare) before reaching to devel is hence 
>  entirely wrong in my opinion. Committees should rubber stamp community 
>  decisions, not drive them.
>   
I agree that committees should not drive decisions. I did not mean to undermine the role
of the Devel list in discussing technical ideas and getting wider feedback from the
development community. I guess there is not an easy equivalent of the Devel list to
Fedora's non-engineering community.


>  As for users communities, yes, that is a good idea. However, so is
> first 
>  discussing this within the engineering contributors community and only once 
>  there is a consensus, involve advocacy / user communities for more feedback.
>   
Is there a plan or process for collecting advocacy / user community feedback for more
feedback?

My concern is this step will not be deemed critical or important enough, and it will be
glossed over. I'm not opposed to development discussions, but I don't see where
user community feedback fits into the existing Change process. Maybe I am missing
something obvious.


>  Hence, I disagree with what you say - discussing this on the devel
> list first is 
>  the best thing to do IMHO. 
This is not how I wanted to represent my position. I'm sorry to have made it appear
that way.


>  Adam Williamson wrote:
>  
>  There is no "why" behind this Change "other than eliminating an
>  admittedly tedious task for the QA team". That's the whole thing. There
>  aren't any "private RH BZ customer tickets". Why would RH customers
>  care about whether or not Fedora blocks on physical optical media
>  booting? 
The QA team has increasing demands for the ways Fedora is changing, and I also understand
how optical drives are not part of those increasing demands. But to me, there is an
opportunity to find a middle ground approach that reduces the work for the QA team without
causing panic and fear in user communities in Global South communities that optical drives
will be unsupported.

Also I'm sorry about the "private RH BZ customer tickets" comment. Sometimes
I am a little jaded as a community volunteer because there are some decisions made that I
cannot always understand or follow. It was distracting for me to mention it here in this
discussion and I didn't intend to make a jab.


>  Adam Williamson wrote:
>  
>  If there are all these thousands of people out there who care deeply
>  about the optical media...wouldn't it be nice if some of them turned up
>  and helped run the tests once in a while?
>   
It would be nice, but this assumes a lot of the people who are most affected. Contributing
to Fedora in free time is a privilege. Some companies strictly forbid employees from
contributing to open source despite using it. Using presence of unpaid volunteers as a
metric of engagement and interest does not match up to me.

That said, I think there is opportunity to improve in attracting contributors. If it is
important to continue the optical drive validation work, it would be cool to see Test Day
events or a page in the Fedora Docs sites about how to run through the QA tests for
optical drive validation. We could rally more people to do these things but we have not
made a good-faith attempt yet at reaching those people and inviting them to the table.
I'm not sure where to find this test case information myself!


>  Very very rarely. As Chris Murphy wrote, by pure coincidence one
> showed
>  up the day before yesterday (to be clear, it has nothing at all to do
>  with this Change proposal, the proposers of the Change were not aware
>  of that bug until well after the Change was submitted). Before that the
>  last time I can find, by searching my Bugzilla mail box for relevant
>  words at least, is 2015:
>  
>  https://bugzilla.redhat.com/show_bug.cgi?id=1250440
>  
>  the last time we had a *fatal* issue that I can find is 2014:
>  
>  https://bugzilla.redhat.com/show_bug.cgi?id=1148087
>  
>  Note, the testing isn't *hard* to do, really, it's just tedious and
>  time consuming. Not just the act of running the test (though that does
>  take quite a while, between the burning process and the boot, media
>  check and install itself), but the fact that it means we need to ensure
>  we have at least a couple of people who still have access to a DVD
>  burner and blank media. 
I'm warming up to an idea that focuses on empowering the community to lead this work
in a sustainable way without mandating the QA team to test these every release. If I could
suggest first steps to one way to "hand-off" to the community, it might be like
this:

1. Publish "Fedora QA test cases" somewhere in the Fedora Docs site for QA:
https://docs.fedoraproject.org/en-US/qa-docs/
2. Write test cases based on the manual work done currently and how to validate success;
publish in docs site
3. Write Community Blog post to point out to community that these docs exist

If you (or anyone) doesn't like my idea, I encourage you to propose what you think
would work. :) I believe there is a winning solution where the QA team is relieved of
tedious work among increasing demands, and the distributed Fedora user community does not
enter a frenzy when they find out optical drives are "unsupported".

Not saying my solution is the winning one but I think this is the desired final-state to
work towards.

[Adam Williamson]

On Tue, 2019-12-17 at 16:25 +0000, Justin W. Flory wrote:
>  > 
>  > Note, the testing isn't *hard* to do, really, it's just tedious and
>  > time consuming. Not just the act of running the test (though that does
>  > take quite a while, between the burning process and the boot, media
>  > check and install itself), but the fact that it means we need to ensure
>  > we have at least a couple of people who still have access to a DVD
>  > burner and blank media.
>  
>  I'm warming up to an idea that focuses on empowering the community to
>  lead this work in a sustainable way without mandating the QA team to
>  test these every release. If I could suggest first steps to one way
>  to "hand-off" to the community, it might be like this:
>  
>  1. Publish "Fedora QA test cases" somewhere in the Fedora Docs site
>  for QA: https://docs.fedoraproject.org/en-US/qa-docs/
>  2. Write test cases based on the manual work done currently and how
>  to validate success; publish in docs site
>  3. Write Community Blog post to point out to community that these
>  docs exist
>  
>  If you (or anyone) doesn't like my idea, I encourage you to propose
>  what you think would work. :) I believe there is a winning solution
>  where the QA team is relieved of tedious work among increasing
>  demands, and the distributed Fedora user community does not enter a
>  frenzy when they find out optical drives are "unsupported". 
Um. I realize these are the avenues you're familiar with, but we
already have a perfectly good, community-facing validation process. We
already have test cases. They're written and they work. They're in the
wiki not on the docs site; this is not a problem, they are both web
pages that community members can visit. (The wiki also has extensive
dynamic templating capabilities which the test cases use frequently;
the docs site...doesn't).

Basically: what's wrong with
https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test
and
https://fedoraproject.org/wiki/QA:Testcase_Boot_default_install
(the test case it links to, for this area) that you think we can fix by
moving the test cases to the docs site and somehow rewriting them (? -
I really don't know what step 2 means).
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Chris Murphy]

On Sat, Dec 14, 2019 at 7:26 AM Justin W. Flory <jflory7(a)gmail.com&gt; wrote:
>  (1) This change affects people differently in different regions of the world
>
>  The Fedora community has large user and contributor communities all over the world.
> Historically, our Ambassadors/Advocates relied on DVD media in these regions to install
> Fedora and promote it at events, because there is not always reliable, consistent Internet
> connection in parts of these regions. Additionally, the hardware that exists in these
> regions is often previous-generation hardware that does not mirror the same hardware
> advances in the West.
>
>  Without more data on DVD media usage to support this Change, I am concerned of the impact
> of this Change on Fedora user and advocacy communities that may still rely on this as a
> vital deliverable to support their community work in promoting Fedora globally. 
Related questions, though possibly tangent to this Change, in the
context of regions where Internet is not as reliable or fast:

Is it typical that installations are not immediately updated? By
default, Fedora Workstation will start downloading updates within
minutes of the first login (following first user creation in GNOME
Initial Setup). Not merely updated repo metadata, but the actual RPMs.
Soon after release, weeks, this first update payload is easily the
size of the Workstation Live ISO. Is it typical to setup a local
mirror to mitigate this problem? If it were easier to setup a local
mirror, or locally mirror a subset of the RPMs in a release, would
that help make netinstall more viable in addition to making it easier
to provide up to date installations?

If it's most helpful to have a self-contained initial installation, is
the current 2GB Workstation Live size limitation actually a negative?
As in, there's generally a desire for more pre-installed applications
and functionality? A larger ISO translates into an even larger update
demand when the time comes, so it's a balancing act of course - but
I'm wondering whether a sub 2GB ISO size for this use case actually
makes things more difficult. Or if it's considered OK as is.

Thanks,

-- 
Chris Murphy

[Gerd Hoffmann]

  Hi,

>  Soon after release, weeks, this first update payload is easily the
>  size of the Workstation Live ISO. Is it typical to setup a local
>  mirror to mitigate this problem?  If it were easier to setup a local
>  mirror, or locally mirror a subset of the RPMs in a release, would
>  that help make netinstall more viable in addition to making it easier
>  to provide up to date installations? 
/me has a local Server mirror for VM installs.

Mirroring the Everything and updates repos is too much data.

Mirroring a subset of the RPMs is too much work (maintaining the subset
you need is a PITA because it constantly changes).

What works best is downloading though a caching proxy.  Needs tweaking
the repofiles though:  Comment out metalink, add baseurl with a fixed
mirror instead, otherwise you'll end up re-downloading unmodified
repodata and packages just because yum/dnf picked another mirror this
time.

Wishlist item:  Can we just have cdn.fedoraproject.org download urls
please?

cheers,
  Gerd

[Adam Williamson]

On Mon, 2019-12-16 at 10:49 +0100, Gerd Hoffmann wrote:
>  
>  Wishlist item:  Can we just have cdn.fedoraproject.org download urls
>  please? 
If you mean 'a URL that redirects you to a mirror that carries the
file', that's what download.fedoraproject.org is.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Gerd Hoffmann]

On Mon, Dec 16, 2019 at 09:00:11AM -0800, Adam Williamson wrote:
>  On Mon, 2019-12-16 at 10:49 +0100, Gerd Hoffmann wrote:
>  > 
>  > Wishlist item:  Can we just have cdn.fedoraproject.org download urls
>  > please?
>  
>  If you mean 'a URL that redirects you to a mirror that carries the
>  file', that's what download.fedoraproject.org is. 
Well, a redirect does't solve the squid caching issue from my previous
mail (which you've snipped) as the proxy would still see the different
mirror hostnames and re-download things when download.fedoraproject.org
picks another mirror for some reason.

cheers,
  Gerd

[Kamil Paral]

On Tue, Dec 17, 2019 at 1:28 PM Gerd Hoffmann <kraxel(a)redhat.com&gt; wrote:

>  On Mon, Dec 16, 2019 at 09:00:11AM -0800, Adam Williamson wrote:
>  > On Mon, 2019-12-16 at 10:49 +0100, Gerd Hoffmann wrote:
>  > >
>  > > Wishlist item:  Can we just have cdn.fedoraproject.org download urls
>  > > please?
>  >
>  > If you mean 'a URL that redirects you to a mirror that carries the
>  > file', that's what download.fedoraproject.org is.
>
>  Well, a redirect does't solve the squid caching issue from my previous
>  mail (which you've snipped) as the proxy would still see the different
>  mirror hostnames and re-download things when download.fedoraproject.org
>  picks another mirror for some reason.
>  
Hello Gerd,
this is also off-topic. Please create a separate thread if you wish to
discuss this further (or anyone else). Thank you.

[Adam Williamson]

On Tue, 2019-12-17 at 13:27 +0100, Gerd Hoffmann wrote:
>  On Mon, Dec 16, 2019 at 09:00:11AM -0800, Adam Williamson wrote:
>  > On Mon, 2019-12-16 at 10:49 +0100, Gerd Hoffmann wrote:
>  > > Wishlist item:  Can we just have cdn.fedoraproject.org download urls
>  > > please?
>  > 
>  > If you mean 'a URL that redirects you to a mirror that carries the
>  > file', that's what download.fedoraproject.org is.
>  
>  Well, a redirect does't solve the squid caching issue from my previous
>  mail (which you've snipped) as the proxy would still see the different
>  mirror hostnames and re-download things when download.fedoraproject.org
>  picks another mirror for some reason. 
Oh, that's what you meant, I see. Sorry, the thing about proxy
downloading wasn't in the context when I replied so I missed that this
was about that.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Frantisek Zatloukal]

On Fri, Dec 13, 2019 at 12:03 PM Miro Hrončok <mhroncok(a)redhat.com&gt; wrote:

>  Juts a random idea, not very thought-out:
>
>  Could we keep optical media bugs reported by users as blocking, but not
>  require
>  it during validation testing?
>
>
>  aka: Fedora QE would no longer have to verify optical media works.
>  but: If a tester finds an optical media  bug, it is still blocking.
>
>  That would still have 2 of the 3 listed benefits. The remaining benefit is
>  arguable (is optical media a corner case? there are no corners on DVD).
>  
It's not a bad idea. I'd still prefer to drop optical media criterion
completely, but your proposal is better than nothing, should mine be
rejected.

[Kamil Paral]

On Thu, Dec 12, 2019 at 9:40 PM Ben Cotton <bcotton(a)redhat.com&gt; wrote:

>  https://fedoraproject.org/wiki/Changes/Drop_Optical_Media_Criterion
>
>  = Drop Optical Media Release Criterion =
>
>  == Summary ==
>  Proposal to make all Fedora optical media non-blocking. This means
>  we'd stop blocking on bugs found during the installation of Fedora
>  from optical media (like CDs and DVDs). This doesn't mean that
>  installation from optical media would stop working, just that the
>  Fedora Release wouldn't be blocked on any issues that can pop up in
>  Fedora installation using this method. Installation from USB devices
>  will remain blocking.
>  
This has been a long discussion. Let me sum up some answers and
misunderstandings, as a member of the QA team.

The sole reason for the proposal is that testing optical media is a long
and tedious process and we believe that their importance has gone down
massively in the last years. We understand that there are people whose
hardware still requires optical media for installation. There will always
be people like that, even in 10 years. And we don't revel in presenting
them with additional obstacles. But we also have duties, priorities and
limited resources, and must regularly re-assess what we do. In our opinion,
optical media have fallen below the cut-off line. Especially with the
recent deprecation of i386 architecture in terms of kernel/boot support, we
assume that the number of affected hardware and people is just a very small
minority in our user base. That's why we want to drop the release-blocking
requirement and invest the time into testing something that affects more
people.

It's very important to understand that dropping a release criterion for
optical boot doesn't mean Fedora can't be installed from a DVD in the
future. The bugs that affect just bare-metal optical booting (and not
virtual machines or usb booting) are very rare. Adam and Chris have
provided some numbers and references. If such a problem is detected soon
enough, we will definitely do our best to make sure it's resolved by the
official release time. In the worst case scenario, where no one spotted it
in advance and all installation media are affected, there are still avenues
for affected users. An older installation medium can be used and the system
upgraded. And older installation medium can be used and pointed at latest
installation repositories (this is not guaranteed to work, but works in
majority of cases). And we can also spin up unofficial install media
post-release, once the bug is fixed (we've done this in the past). There
are even community members who do these "media refreshes" regularly.
Overall, yes, it might be uncomfortable if you have such hardware, but it's
*not* game over.

It's also important to understand the current state of optical media
release criteria. We've dropped the blocker requirement for most
installation media two years ago. Only Everything netinst and Workstation
Live remained. This proposal suggests that we drop these last two as well.
If you're concerned about Server DVD or KDE Live or something else - there
is no change for you.

Regarding virtual machines, you can rest assured that we'll still block on
VMs booting from ISO files mounted as virtual optical drives. If Adam
thinks this is a bit under-defined at the moment, we'll define it properly
as part of this proposal.

Regarding the topic of how many laptops/workstations/servers sell with an
optical drives nowadays - this is completely irrelevant, let's just not
waste time with this discussion. The important topic is how many of
existing hardware can't boot using other means (that would be mostly USB
for laptops/workstations and network for servers).

Also, this is not something that has been announced suddenly. We've been
discussing this for multiple years, and a year ago it was even proposed by
Matthew Miller (Fedora Project Leader). This gets perhaps more visibility
due to being a Change proposal, as we usually discuss QA matters in test or
test+devel lists. And that's fine, we very much appreciate feedback. I'm
just clarifying this is not some shocking news of the year.

To reply to Justin Flory about Fedora Mindshare Committee - I think this is
more of an engineering decision, really. Of course you'll find users who
will want optical boot 100% supported (and that's true probably about
anything). The question is how much testing we can provide and whether we
want to block the whole release train on such issues, and that's likely
just an engineering prioritization. Of course it's good to have user
feedback.

Regarding Miro Hrončok's proposal "let QA skip testing, but block on it if
somebody else finds the problem" - yes, it's possible. QA is by definition
best effort, even though we've considered a full test matrix coverage
somewhat mandatory lately. We do practice this approach for many criteria
for which we don't even have test cases written. In terms of boot support,
though, I'm not particularly fond of it. Without regular QA testing, this
will have a tendency to get discovered very shortly before Final release,
and then people will be just mad at QA for not detecting it sooner.

If anyone wants to make sure optical media breakage doesn't happen -
please, help us. We announce new candidate composes in test-announce list
regularly. Download the image, burn it, install it, and fill out the
correct field in the installation matrix. Do this from time to time during
pre-branching period, and regularly for every proposed Beta and Final
release candidate. We'll be very grateful. And that is independent on
whether optical media keep being blocking or are no longer blocking. The
test feedback is always helpful. And if the bugs are on our radar, we'll do
our best to have them resolved by the final release day.

Kamil

[John M. Harris Jr]

On Monday, December 16, 2019 5:13:11 AM MST Kamil Paral wrote:
>  It's very important to understand that dropping a release
> criterion for
>  optical boot doesn't mean Fedora can't be installed from a DVD in the
>  future. The bugs that affect just bare-metal optical booting (and not
>  virtual machines or usb booting) are very rare. 
Sure, but it still happens, and it's low hanging fruit to make sure it works 
so that these users don't wind up unable to install Fedora.

>  Adam and Chris have provided some numbers and references. If such a
>  problem is detected soon enough, we will definitely do our best to make
>  sure it's resolved by the official release time. 
Where are these numbers and references?

>  In the worst case scenario, where no one spotted it in advance and
> all
>  installation media are affected, there are still avenues for affected users. 
Like what? Anything that the end user will actually go through the trouble of? 
Put on your user hat for a minute here. You want to install Fedora. You've got 
a system that will only boot via CD/DVD, and a DVD that won't boot. What do 
you do?

>  An older installation medium can be used and the system upgraded. And
> older
>  installation medium can be used and pointed at latest installation
>  repositories (this is not guaranteed to work, but works in majority of  
cases).

This is just an excuse for exactly what I said would happen: A release with 
broken optical install media. This is easily avoidable.

>  And we can also spin up unofficial install media post-release, once
>  the bug is fixed (we've done this in the past). There are even community
>  members who do these "media refreshes" regularly. Overall, yes, it might be
>  uncomfortable if you have such hardware, but it's *not* game over. 
Considering that the other major options still have working optical install 
media, it basically is game over. These users would likely flock to a distro 
that isn't supporting their primary install method anymore, such as openSUSE, 
Ubuntu or Debian.

-- 
John M. Harris, Jr.
Splentity

[Kamil Paral]

On Mon, Dec 16, 2019 at 4:06 PM John M. Harris Jr <johnmh(a)splentity.com&gt;
wrote:

>  > An older installation medium can be used and the system
> upgraded. And
>  older
>  > installation medium can be used and pointed at latest installation
>  > repositories (this is not guaranteed to work, but works in majority of
>  cases).
>
>  This is just an excuse for exactly what I said would happen: A release
>  with
>  broken optical install media. This is easily avoidable.
>  
John, you keep repeating the same arguments over and over. You don't need
to reply to each and every mail and state your position. If you think that
being overly vocal will change people's perception of the proposal - I
don't think so. It might just change their perception of you. We've heard
you. We understand your position. Please don't spam this thread so hard -
make it easier for others to read it and participate in it as well. Thank
you.

If you care so deeply about optical media working in Fedora, the best thing
you can do is to regularly participate in testing. Fedora is driven by
people who work on stuff in areas they're passionate about. This can be
your area and we'll certainly welcome your contribution. Fedora 32 release
cycle is coming up soon.

[John M. Harris Jr]

On Monday, December 16, 2019 12:16:29 PM MST Kamil Paral wrote:
>  On Mon, Dec 16, 2019 at 4:06 PM John M. Harris Jr
> <johnmh(a)splentity.com&gt;
>  
>  wrote:
>  > > An older installation medium can be used and the system upgraded. And
>  > 
>  > older
>  > 
>  > > installation medium can be used and pointed at latest installation
>  > > repositories (this is not guaranteed to work, but works in majority of
>  > 
>  > cases).
>  > 
>  > This is just an excuse for exactly what I said would happen: A release
>  > with
>  > broken optical install media. This is easily avoidable.
>  
>  John, you keep repeating the same arguments over and over. You don't need
>  to reply to each and every mail and state your position. If you think that
>  being overly vocal will change people's perception of the proposal - I
>  don't think so. It might just change their perception of you. We've heard
>  you. We understand your position. Please don't spam this thread so hard -
>  make it easier for others to read it and participate in it as well. Thank
>  you.
>  
>  If you care so deeply about optical media working in Fedora, the best thing
>  you can do is to regularly participate in testing. Fedora is driven by
>  people who work on stuff in areas they're passionate about. This can be
>  your area and we'll certainly welcome your contribution. Fedora 32 release
>  cycle is coming up soon. 
I'd be more than happy to volunteer my time to work on that.

As for "making the same argument several times", that is likely the case, in 
those instances I have recently started referring to the earlier email in the 
thread. That said, when a different context comes up, it makes sense to reply 
to the new context.

-- 
John M. Harris, Jr.
Splentity

[Adam Williamson]

On Mon, 2019-12-16 at 13:13 +0100, Kamil Paral wrote:
>  It's also important to understand the current state of optical
> media
>  release criteria. We've dropped the blocker requirement for most
>  installation media two years ago. Only Everything netinst and Workstation
>  Live remained. This proposal suggests that we drop these last two as well.
>  If you're concerned about Server DVD or KDE Live or something else - there
>  is no change for you. 
As per my mail earlier in the thread, I'd suggest this is inaccurate.

Back at the time we reduced the set of tested images, the idea was
explicitly that we can test just *one* live image and just *one*
installer image as 'representatives' of the others. If one live image
boots, we can be fairly sure all live images boot. If one installer
image boots, we can be fairly sure all installer images boot. This is
because all lives are built identically so far as boot stuff goes, as
are all installer images.

This is *specifically* the idea we sold that change on, so it's kinda
logically invalid to then try and sell *this* Change on "well we only
test these two images ANYWAY so if you don't use them you shouldn't
care". It'd be trying to have things two opposite ways.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Kamil Paral]

On Mon, Dec 16, 2019 at 6:04 PM Adam Williamson <adamwill(a)fedoraproject.org&gt;
wrote:

>  On Mon, 2019-12-16 at 13:13 +0100, Kamil Paral wrote:
>  > It's also important to understand the current state of optical media
>  > release criteria. We've dropped the blocker requirement for most
>  > installation media two years ago. Only Everything netinst and Workstation
>  > Live remained. This proposal suggests that we drop these last two as
>  well.
>  > If you're concerned about Server DVD or KDE Live or something else -
>  there
>  > is no change for you.
>
>  As per my mail earlier in the thread, I'd suggest this is inaccurate.
>
>  Back at the time we reduced the set of tested images, the idea was
>  explicitly that we can test just *one* live image and just *one*
>  installer image as 'representatives' of the others. If one live image
>  boots, we can be fairly sure all live images boot. If one installer
>  image boots, we can be fairly sure all installer images boot. This is
>  because all lives are built identically so far as boot stuff goes, as
>  are all installer images.
>
>  This is *specifically* the idea we sold that change on, so it's kinda
>  logically invalid to then try and sell *this* Change on "well we only
>  test these two images ANYWAY so if you don't use them you shouldn't
>  care". It'd be trying to have things two opposite ways.
>  
Fair point, that was an invalid argument from my side. Even though e.g.
Server DVD hasn't been optical-blocking for some time, it still gained the
benefits of test coverage or fixes in other media which were
optical-blocking.

[Justin W. Flory]

>  Kamil wrote:
>  
>  This has been a long discussion. Let me sum up some answers and
>  misunderstandings, as a member of the QA team.
>   
Hey Kamil, I wanted to say thanks for adding this perspective. I missed this post in my
last reply because there are a lot of posts. I learned a lot about Fedora QA reading this
just now. :)

>  To reply to Justin Flory about Fedora Mindshare Committee - I think
> this is
>  more of an engineering decision, really. Of course you'll find users who
>  will want optical boot 100% supported (and that's true probably about
>  anything). The question is how much testing we can provide and whether we
>  want to block the whole release train on such issues, and that's likely
>  just an engineering prioritization. Of course it's good to have user
>  feedback.
>   
I think I misrepresented my point by mentioning the Mindshare Committee specifically.
Instead of it being exclusively an engineering decision, can it not be an engineering and
community decision? By raising the importance of user/community feedback, I don't mean
to undermine engineering feedback and discussion. But in this specific area (i.e. hardware
changes), Fedora has not done a good job engaging regions of the world that often have
vastly different standards of consumer-grade hardware.

This might not affect people **using** Fedora for enterprise purposes but it does impact
the ability of people like volunteers to **access** Fedora on their own machines,
especially when contributing guidelines across Pagure projects often assume the reader
runs Fedora. I think we undervalue the role of older consumer hardware because we look at
it from an enterprise-demands P.O.V. A lot of the feedback that comes into Fedora comes
from that perspective. Consumer-grade hardware varies more and not everyone has access to
the same set of resources.

If it feels like I'm harping, it is because there are already some frustrations in the
non-engineering parts of the Fedora community and my concern is that this Change would be
one more loss for the volunteer community. For perspective, we have existing communities
of people in regions who could be adversely affected by this Change:

https://communityblog.fedoraproject.org/tag/latam/

https://communityblog.fedoraproject.org/tag/india/

>  Regarding Miro Hrončok's proposal "let QA skip testing, but
> block on it if
>  somebody else finds the problem" - yes, it's possible. QA is by definition
>  best effort, even though we've considered a full test matrix coverage
>  somewhat mandatory lately. We do practice this approach for many criteria
>  for which we don't even have test cases written. In terms of boot support,
>  though, I'm not particularly fond of it. Without regular QA testing, this
>  will have a tendency to get discovered very shortly before Final release,
>  and then people will be just mad at QA for not detecting it sooner.
>   
Is it absurd if it blocked an N+1 release? I don't have enough perspective if this
could reduce the pinch point around a release day while also still validating the
importance of these issues to the community.

Alternatively, this could make the requirements too complex where few people remember this
rule in practice.

>  If anyone wants to make sure optical media breakage doesn't
> happen -
>  please, help us. We announce new candidate composes in test-announce list
>  regularly. Download the image, burn it, install it, and fill out the
>  correct field in the installation matrix. Do this from time to time during
>  pre-branching period, and regularly for every proposed Beta and Final
>  release candidate. We'll be very grateful. And that is independent on
>  whether optical media keep being blocking or are no longer blocking. The
>  test feedback is always helpful. And if the bugs are on our radar, we'll do
>  our best to have them resolved by the final release day.
>   
I wonder what a way of handing these tests off to the community (with some guidance from
Fedora QA team) might look like.

[John M. Harris Jr]

On Tuesday, December 17, 2019 10:02:42 AM MST Justin W. Flory wrote:
>  This might not affect people **using** Fedora for enterprise purposes
Well, this definitely affects those using Fedora for enterprise purposes. It's 
incredible how much businesses still rely on optical media for these things.

-- 
John M. Harris, Jr.
Splentity

[Chris Adams]

Once upon a time, John M. Harris Jr <johnmh(a)splentity.com&gt; said:
>  On Tuesday, December 17, 2019 10:02:42 AM MST Justin W. Flory wrote:
>  > This might not affect people **using** Fedora for enterprise purposes
>  
>  Well, this definitely affects those using Fedora for enterprise purposes. It's 
>  incredible how much businesses still rely on optical media for these things. 
Again, you're projecting from an anecdote of one.  My anecdote of one is
that the vast majority of system in my company (around 400 employees
IIRC) don't have an optical drive.  I'm actually not sure if any of the
desktops have one (since every once in a while someone will come around
looking for a USB optical drive, usually to burn something to send to
someone outside the company).  OS installs (mostly Windows, sigh) are
done from USB flash drives.

We had some blank media on the shelf, but I think it got thrown away
when we moved offices early this year, because nobody actually had a
drive to put it in.
-- 
Chris Adams <linux(a)cmadams.net&gt;

[Solomon Peachy]

On Tue, Dec 17, 2019 at 07:33:12PM -0600, Chris Adams wrote:
>  Again, you're projecting from an anecdote of one.  My anecdote of
> one is
>  that the vast majority of system in my company (around 400 employees
>  IIRC) don't have an optical drive.  I'm actually not sure if any of the
>  desktops have one (since every once in a while someone will come around 
None of the IT-department-provided systems at my last two employers came 
with optical drives, and even if requested it would have been fulfilled 
in the form of a portable USB drive sent along separately.

"Enterprises" tend to refresh their equipment every three years or so, 
and it's been nearly two full refresh cycles since CD drives were 
considered standard equipment for end-user systems. It's been even 
longer for servers; after all, why waste the money and physical space on 
an optical drive that will only be used once?

Granted, there's a long tail of older equipment that was 
shipped/equipped with a CD drive, but let's be honest, you'd have to go 
back more than a decade to find something that can't also boot off a USB 
stick -- placing one firmly in the territory where performance, 
operating costs, and especially reliability of that old equipment is of 
significant concern.

(FWIW, I have Fedora installed on two such systems, and yes, their 
 reliability has taken a significant nosedive..)

 - Solomon
-- 
Solomon Peachy			       pizza at shaftnet dot org
High Springs, FL                          ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.

[John M. Harris Jr]

On Tuesday, December 17, 2019 7:51:38 PM MST Solomon Peachy wrote:
>  On Tue, Dec 17, 2019 at 07:33:12PM -0600, Chris Adams wrote:
>  > Again, you're projecting from an anecdote of one.  My anecdote of one is
>  > that the vast majority of system in my company (around 400 employees
>  > IIRC) don't have an optical drive.  I'm actually not sure if any of the
>  > desktops have one (since every once in a while someone will come around
>  
>  None of the IT-department-provided systems at my last two employers came
>  with optical drives, and even if requested it would have been fulfilled
>  in the form of a portable USB drive sent along separately.
>  
>  "Enterprises" tend to refresh their equipment every three years or so,
>  and it's been nearly two full refresh cycles since CD drives were
>  considered standard equipment for end-user systems. It's been even
>  longer for servers; after all, why waste the money and physical space on
>  an optical drive that will only be used once? 
I'd agree, in most environments, most end user systems are generally refreshed 
in a timeline under 5 years. For servers, it varies from under 10 years to 
never. There is definitely hardware that never gets updated though, even if 
the OS is updated, or re-installed.

It's simply not the case that optical drives have been uncommon on end-user 
systems for over 6 years. As we found earlier in this thread, they're on 1/3rd 
of stock desktops from a standard consumer vendor, and on most systems that 
are sold to enterprise customers as designed to run RHEL, at least from one of 
the major vendors of enterprise hardware.

>  Granted, there's a long tail of older equipment that was
>  shipped/equipped with a CD drive, but let's be honest, you'd have to go
>  back more than a decade to find something that can't also boot off a USB
>  stick -- placing one firmly in the territory where performance,
>  operating costs, and especially reliability of that old equipment is of
>  significant concern. 
This is simply not the case. Please see the earlier posts in this thread on 
that topic for just a few examples. It's certainly true that newer pre-built 
systems are less likely to come with an optical drive stock. That said, Fedora 
runs on much more than just systems produced within the last 10 years. For 
example, the laptop I'm using to send this message is now 11 years old. All of 
my personal servers are between 9 and 12 years old. These all run Fedora, 
without issue. I'm definitely not the only one running Fedora on "old" 
hardware.

>  (FWIW, I have Fedora installed on two such systems, and yes, their
>   reliability has taken a significant nosedive..) 
How so? Do you believe it's an
issue with Fedora, or with the systems 
themselves? I'd be happy to help you diagnose this off-list, or on the users 
list.

-- 
John M. Harris, Jr.
Splentity

[Solomon Peachy]

On Tue, Dec 17, 2019 at 08:09:14PM -0700, John M. Harris Jr wrote:
>  It's simply not the case that optical drives have been uncommon
> on 
>  end-user systems for over 6 years. As we found earlier in this thread, 
>  they're on 1/3rd of stock desktops from a standard consumer vendor, 
>  and on most systems that are sold to enterprise customers as designed 
>  to run RHEL, at least from one of the major vendors of enterprise 
>  hardware. 
And that only matters if those systems won't boot off a USB stick.  
These days, folks are far, far more likely to have a random 2GB USB 
stick lying around than blank DVD media. 

(And even a bottom-of-the-barrel USB stick is going to perform vastly 
 better than an optical drive.  Two orders of magnitude better access 
 time, and all that..)

>  Fedora runs on much more than just systems produced within the last
> 10 
>  years. For example, the laptop I'm using to send this message is now 
>  11 years old. All of my personal servers are between 9 and 12 years 
>  old. These all run Fedora, without issue. I'm definitely not the only 
>  one running Fedora on "old" hardware. 
Not counting a couple of Raspberry Pi units, the newest system I have 
deployed is a 5-year-old laptop with an increasingly-flaky motherboard.  

The oldest dates from 2007, and is only in service because its erstwhile 
replacement spectacularly expelled its magic smoke.

FWIW, most of my upgrades have been triggered by hardware failures.

>  How so? Do you believe it's an issue with Fedora, or with the
> systems 
>  themselves? I'd be happy to help you diagnose this off-list, or on the 
>  users list. 
Oh, it's purely hardware reliability, nothing to do with Fedora itself.

Normal stuff like hard drives, fans, power supplies, and expired CMOS 
batteries.  Relatively hostile environmental conditions don't help.

 - Solomon
-- 
Solomon Peachy			       pizza at shaftnet dot org
High Springs, FL                          ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.

[John M. Harris Jr]

On Tuesday, December 17, 2019 6:33:12 PM MST Chris Adams wrote:
>  Once upon a time, John M. Harris Jr <johnmh(a)splentity.com&gt;
> said:
>  
>  > On Tuesday, December 17, 2019 10:02:42 AM MST Justin W. Flory wrote:
>  > 
>  > > This might not affect people **using** Fedora for enterprise purposes
>  > 
>  > 
>  > Well, this definitely affects those using Fedora for enterprise purposes.
>  > It's  incredible how much businesses still rely on optical media for
>  > these things.
>  
>  Again, you're projecting from an anecdote of one.  My anecdote of one is
>  that the vast majority of system in my company (around 400 employees
>  IIRC) don't have an optical drive.  I'm actually not sure if any of the
>  desktops have one (since every once in a while someone will come around
>  looking for a USB optical drive, usually to burn something to send to
>  someone outside the company).  OS installs (mostly Windows, sigh) are
>  done from USB flash drives.
>  
>  We had some blank media on the shelf, but I think it got thrown away
>  when we moved offices early this year, because nobody actually had a
>  drive to put it in. 
That's not what I'm talking about. I work for a company of ~18,000 employees, 
and the vast majority of systems do have optical drives. However, that doesn't 
matter.

As you noted about "to send someone outside of the company", enterprise 
customers still use optical media a lot more than you might expect. For 
example, recently I've been asked to maintain a RHEL install disk with 
packages from epel and a custom kickstart, for re-installs when my team isn't 
available.

In environments where you can do it, I'd strongly recommend using a PXE server 
when deploying large numbers of systems, which I'd personally describe as any 
environment with over 10 systems.

-- 
John M. Harris, Jr.
Splentity

[Matthew Miller]

On Tue, Dec 17, 2019 at 07:33:12PM -0600, Chris Adams wrote:
>  > Well, this definitely affects those using Fedora for enterprise
>  > purposes. It's incredible how much businesses still rely on optical
>  > media for these things.
>  Again, you're projecting from an anecdote of one.  My anecdote of one is
>  that the vast majority of system in my company (around 400 employees
>  IIRC) don't have an optical drive.  I'm actually not sure if any of the 
I think John is talking about rackmount hardware. But John, in this case,
aren't you booting from virtualized media via idrac (or whatever brand
equivalent), not literally a burned physical DVD?

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

[John M. Harris Jr]

On Wednesday, December 18, 2019 10:01:02 AM MST Matthew Miller wrote:
>  On Tue, Dec 17, 2019 at 07:33:12PM -0600, Chris Adams wrote:
>  
>  > > Well, this definitely affects those using Fedora for enterprise
>  > > purposes. It's incredible how much businesses still rely on optical
>  > > media for these things.
>  > 
>  > Again, you're projecting from an anecdote of one.  My anecdote of one is
>  > that the vast majority of system in my company (around 400 employees
>  > IIRC) don't have an optical drive.  I'm actually not sure if any of the
>  
>  
>  I think John is talking about rackmount hardware. But John, in this case,
>  aren't you booting from virtualized media via idrac (or whatever brand
>  equivalent), not literally a burned physical DVD? 
In one of the environments that I support at $WORK, I wouldn't have an option 
other than physical optical media. However, you are correct in that the 
example I provided earlier was for iDRAC (or equivalent) optical drive 
emulation. Several times, I have found images which would work with qemu's -
cdrom option, but not with an iDRAC's VirtualCD implementation, or in an 
actual optical drive.

-- 
John M. Harris, Jr.
Splentity

[Miro Hrončok]

On 12. 12. 19 21:37, Ben Cotton wrote:
>  https://fedoraproject.org/wiki/Changes/Drop_Optical_Media_Criterion
>  
>  = Drop Optical Media Release Criterion =
>  
>  == Summary ==
>  Proposal to make all Fedora optical media non-blocking. This means
>  we'd stop blocking on bugs found during the installation of Fedora
>  from optical media (like CDs and DVDs). This doesn't mean that
>  installation from optical media would stop working, just that the
>  Fedora Release wouldn't be blocked on any issues that can pop up in
>  Fedora installation using this method. Installation from USB devices
>  will remain blocking. 
One more thing I have relized quite recently is that we still offer the ISO file 
as a DVD ISO on https://getfedora.org/en/workstation/download/

While technically, this is correct (the best kind of correct), maybe we should 
rebrand it somehow if we consider optical media obsolete?

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok