On Thu, Jul 11, 2019 at 9:23 AM Brian (bex) Exelbierd
On Mon, Jul 8, 2019 at 9:47 PM Bruno Wolff III <bruno(a)wolff.to> wrote:
> On Tue, Jul 02, 2019 at 13:43:49 -0400,
> Matthew Miller <mattdm(a)fedoraproject.org> 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
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
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!