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¢. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/devel@xxxxxxxxxxxxxxxxxxxxxxx
