> 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. _______________________________________________ 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
