On Thu, 11 Jul 2019 at 11:08, Neal Gompa <ngompa13(a)gmail.com> wrote:
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
> > >recommended one. I can definitely see the appeal -- although we
> > >targetted gamers formally except through the Games spin (which
> > >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
> > >large elephant-in-the-room that is Nvidia. Despite awesomeness from
> > >open source driver recently, and Intel integrated video good enough
> > >lot of basic gaming, Nvidia still has a near monopoly.
> > I don't see us becoming _the_ supported Steam distribution unless we
> > willing to block updates to things to not break Steam (which might
> > 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
> 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...
I believe there are multiple efforts to do this. The one that is being used
by some groups is https://github.com/puiterwijk/mbbox
I believe that mizdebsk and some others also have their own similar efforts.
真実はいつも一つ！/ Always, there's only one truth!
council-discuss mailing list -- council-discuss(a)lists.fedoraproject.org
To unsubscribe send an email to
Fedora Code of Conduct:
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
Stephen J Smoogen.