On Tue, Jul 2, 2019 at 8:42 PM Greg DeKoenigsberg <greg.dekoenigsberg@xxxxxxxxx> wrote: > > On Tue, Jul 2, 2019 at 2:18 PM Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> wrote: > > > > So, a lot of people have been asking me about this! Steam, of course, is a a > > popular platform for gaming, and it runs on Linux. Valve, the company behind > > it, puts a lot of resources into gaming on Linux (including working on open > > source video drivers). Until now, they'd explicitly endorsed and supported a > > specific non-Fedora Linux distro. However, there's been some changes > > which you can read about in this forum post: > > https://steamcommunity.com/app/221410/discussions/0/1640915206447625383/, > > which says in part: > > > > The Linux landscape has changed dramatically since we released the > > initial version of Steam for Linux, and as such, we are re-thinking how > > we want to approach distribution support going forward. There are several > > distributions on the market today that offer a great gaming desktop > > experience such as Arch Linux, Manjaro, Pop!_OS, Fedora, and many others. > > We'll be working closer with many more distribution maintainers in the > > future. [...] > > > > Several people have suggested to me that it'd be awesome for a Fedora > > offering to be _the_ supported Steam distribution. Or at least, a formally > > recommended one. I can definitely see the appeal -- although we haven't > > targetted gamers formally except through the Games spin (which showcases > > open source gaming), gaming is generally pretty important to the > > student/academic audience we'd like to reach. > > > > But, of course, Steam is a proprietary platform, and gaming comes with the > > large elephant-in-the-room that is Nvidia. Despite awesomeness from the AMD > > open source driver recently, and Intel integrated video good enough for a > > lot of basic gaming, Nvidia still has a near monopoly. > > > > I don't have any specific requests or direction from the informal > > conversations we've had with Valve so far, but I imagine that in order to > > really make a Fedora edition or spin their official recommendation, they'd > > want some kind of consideration given to problems that might come up with > > their proprietary system (or with the Nvidia driver). We've traditionally > > had bright line here, where while we may provide advice and point to > > workarounds when there's a problem with popular proprietary software (like > > Steam games, even -- see this from F26 > > https://fedoraproject.org/wiki/Common_F26_bugs), we don't block or slip the > > release for them. > > > > I know this a contentious topic with a lot of different opinions, but let's > > not let that stop us from talking about it. What _are_ our options here, and > > what are we willing to do? > > > > For example, maybe we would not slip the general release, but would allow a > > Fedora-branded spin to delay release until some bug is worked out. Or, we > > could decide that we want to stick to our all-open-source criterion but > > interested teams could work with Valve to be aware of our release schedule > > and make sure they're able to test and get things working _before_ we hit > > release freeze. If it comes to it, maybe we'd allow Fedora editions or spins > > that want to and which have Steam installed from a third-party repository to > > warn of potential problems before upgrading. These are just some thoughts, > > not specific plans.... I can imagine a range of possibilities. > > > > In any case, let's talk about the pros and cons here and what we can gain > > for Fedora and for our open source and free software cause, and what we're > > able to do within our values to accomplish that. > > OK, want to make sure I understand here before I opine. Which is not > how it usually goes. :) > > The opportunity is to convince Valve to say, officially, "if you want > to get the best Steam experience, you should go install Fedora first." > Is that right? > > Because if that is the actual opportunity, and we think it's a > realistic goal, then I think we should pursue it with whatever > resources we might reasonably commit, and make any compromises that we > might reasonably make. Including close coordination of release > activities. > > Having a spiffy Ansible role to get Steam properly configured, > including configuration of third party installs, could also be quite > nice. ;) I propose we consider pushing our end-state further. I'd LOVE to see Valve produce a Fedora Remix that has their code pre-installed (this presumes they have code we can't distribute - I don't know if this is the case). This way we have them, ideally saying three things: 1. The best desktop Linux experience for Steam is on Fedora (i.e. go getfedora.org now!) 2. Here is an ansible role/script/method to add Steam to your existing Fedora install 3. Want a short cut, here is our remix that brings Fedora together with Steam. This is how we test and QA our builds. This gets you Steam and everything that is part of regular Fedora. The committing resources is the hard part.for the community. I think this means asking Fedora QA to help Valve land appropriate gating (?) tests in rawhide in a "train them" model, not a "do it for them and maintain it" model. This would let Valve get rawhide feedback and possibly help us gate on bugs. Hopefully release engineering and our friends in the RIT remix can help them figure out how to get a remix rolling in the same way. Lastly, our friends at ansible should be able to onboard their role in to Galaxy and this would make a great quick doc. This puts a lot of the work on Valve to become contributors to Fedora (a win for everyone) and encourages us to both live our mission (the best platform for your user's solution ...) and to keep our onboarding program going strong. These specific goals with QA and Release Engineering also help improve our docs to make it easier for the next "Valve." regards, bex > > --g > > > > > -- > > Matthew Miller > > <mattdm@xxxxxxxxxxxxxxxxx> > > Fedora Project Leader > > _______________________________________________ > > council-discuss mailing list -- council-discuss@xxxxxxxxxxxxxxxxxxxxxxx > > To unsubscribe send an email to council-discuss-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/council-discuss@xxxxxxxxxxxxxxxxxxxxxxx > _______________________________________________ > council-discuss mailing list -- council-discuss@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to council-discuss-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/council-discuss@xxxxxxxxxxxxxxxxxxxxxxx -- Brian "bex" Exelbierd (he/him/his) Fedora Community Action & Impact Coordinator @bexelbie | http://www.winglemeyer.org bexelbie@xxxxxxxxxx | bex@xxxxxxxxx _______________________________________________ council-discuss mailing list -- council-discuss@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to council-discuss-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/council-discuss@xxxxxxxxxxxxxxxxxxxxxxx
