On Thu, Jul 11, 2019 at 9:23 AM Brian (bex) Exelbierd <bexelbie@xxxxxxxxxx> wrote: > > On Mon, Jul 8, 2019 at 9:47 PM Bruno Wolff III <bruno@xxxxxxxx> wrote: > > > > On Tue, Jul 02, 2019 at 13:43:49 -0400, > > Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> wrote: > > > > > >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 see us becoming _the_ supported Steam distribution unless we are > > willing to block updates to things to not break Steam (which might include > > proprietary video drivers). > > > > I don't think that is a good trade off. Certainly working with them to > > improve things for everybody is a laudable goal. > > I would like to believe there is a middle ground here. I don't know > that Fedora should block on things required by Steam, but I also think > we should work on enabling people, like Valve, to use Fedora as a > platform. To that end, I think we need to double-down on our work to > accomplish two goals: > > 1) Enable CI, gating and non-gating that will allow, for example, > Fedora workstation to gate certain changes, and a Valve remix to be > notified that a change is breaking them before it is time for them to > ship. > If we can get Fedora CI figured out, this would be great. > 2) Enable differential ship dates for our outputs. This would allow > spins, labs, and by extension remixes the ability to ship when they > are ready, not just when our editions are ready. Remixes can do this > today, but we need to make it easier for them to integrate with our > buildsystems where appropriate and to get messages to trigger theirs > where appropriate. > This is a bit harder to do right now, because the interconnect mechanism in Koji doesn't do a lot right now. And I'm pretty sure MBS isn't helping with that... But if we could aim to beef up our tooling to support this, then that is a huge potential opportunity, not just with Valve, but anyone who is downstream of us using Koji to build their deliverables. I've got some specific ideas of what I'd like to see for this, but this is probably not the right list to talk about them. But I would also like to add a third pillar to this: The way to build Fedora (and derivatives) needs to be fully documented and easily reproducible, infrastructure and tooling wise. Right now, it's not very easy to set up a Koji system and configure it to build packages and media. There's a somewhat incomplete doc in the Koji docs about basic server setup (which didn't work when I tried it) and some blog posts on the internet about setting up Koji (which went a bit better...). Also we're in the middle of some of the biggest changes to how stuff is built in Fedora, and I'm pretty sure everyone else is having a hard time keeping up with the changes. If we want people to be able to build on top of Fedora leveraging our tools, we need to make these tools more accessible, usable, and deployable. As an example of "easy to access, use, and deploy", the openSUSE guys have an "OBS in a box" appliance image that you can use to set up your own copy of their build system, which will interconnect with the openSUSE Build Service by default and let you access those resources for your own purposes (including triggering builds when upstream changes occur!). I want something like that for Fedora's stuff, and I'd be happy to help make it. I just don't know how to yet... -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
