This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts today, Tuesday 20th May and closes promptly at 23:59:59 UTC on Monday, 2 June 2025.

Interview with Michel Lind

  • FAS ID: sallima
  • Matrix Rooms: Fedora Devel, Fedora ELN, EPEL, Python, Releng, Rust, Security, Centos-Hyperscale, centos-promo, centos-proposed-updates

Questions

Why do you want to be a member of FESCo and how do you expect to help steer the direction of Fedora?

I have been active in the Fedora community since almost the very beginning (see also the next question), and an elected member of FESCo since the F40 election cycle. The project is facing some interesting set of challenges at the moment – from making infrastructure more scalable and robust in the face of AI scrapers, to making sure packagers are set up for success, or even rethinking long standing policies around what to package and how to package them. If reelected, I hope to continue working on policy changes that balance the interest of package maintainers and provenpackagers, and contribute my perspective as someone paid to work on open source but not on behalf of the project’s primary sponsor.

How do you currently contribute to Fedora? How does that contribution benefit the community?

I’ve been doing packaging for RPM based distros since the Red Hat Linux days, and joined Fedora early on during the Fedora Core days. I’m a proven packager and a packager sponsor, and am currently actively maintaining packages both personally and in the Rust, EPEL, ELN, Python, Lua, and (to a certain extent) Golang SIGs.

My $dayjob at Meta pays me to contribute to Linux Userspace projects, of which Fedora is currently the main focus as the upstream to CentOS Stream and other Enterprise Linux distributions (RHEL etc.); my focus has been on automation to make bootstrapping EPEL for new Stream releases easier with tools such as ebranch and Package of Interest tracker. Most recently, I co-founded the CentOS Proposed Updates SIG, making it possible for users of CentOS Stream to get early access to critical MRs before they officially ship in CentOS Stream, and I am leading the effort to backport the latest GNOME to CentOS Stream as part of the Hyperscale SIG, in the process driving some packaging cleanups benefiting GNOME packaging in both Fedora and future CentOS / EL releases.

I have landed multiple change proposals in the past – most notably around Btrfs and systemd-oomd. Most recently, for the F42 cycle I implemented changes introducing an optional dependency generator for GNOME Shell extensions, reworking how the Django web framework is packaged, and deprecating python-pytest-runner.

How do you handle disagreements when working as part of a team?

In my experience, disagreements are often caused by misunderstandings, and I would try to clear them in one-to-one interactions whenever possible rather than having a public spat; in open source work in particular, given that the participants are often either volunteers or people working for other companies, it’s better to go slower and accommodate the concern of others rather than trying to push my ideas through before gaining consensus.

Sometimes consensus can’t be immediately reached – there have been cases where in hindsight we should refrain from taking irreversible action prematurely, and other cases where discussion is not going anywhere and we should just take a decision to drop a certain topic. One develops a feel for this over time, and I hope I can raise concerns over this more effectively in future terms.

What else should community members know about you or your position

I work for Meta – which runs CentOS Stream on millions of bare metal servers and in containers. I hope I have demonstrated over the past year in FESCo, and over a longer period in my other Fedora and CentOS engagements, that I try to put the community first and not let my employer’s interest override my responsibility to the community.

My wife and I are parents to a cat and a boy, and love cats and dogs equally.