This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors who are a member of at least one non-CLA group. The voting period starts on Thursday, 21 November and closes promptly at 23:59:59 UTC on Thursday, 5 December 2019.

Interview with Fabio Valentini

  • Fedora account: decathorpe
  • IRC nick: decathorpe (found in fedora-{golang,java,python,ruby,rust,stewardship,meeting*})
  • Fedora user wiki page


Describe some of the important technical issues you foresee affecting the Fedora community. What insight do you bring to these issues?

One of the big issues I see today is the increasingly large number of packages that fail to build or install on fedora, which seems to have about doubled between Fedora 29 and rawhide, according to my data. I am trying to reintroduce a regular dependency check report for rawhide (and maybe stable/testing as well), which would at least make the problem more visible, and provide pointers to the most problematic missing dependencies.

There’s also the fallout from the – currently incomplete (or broken, depending on who you ask) – implementation of Modularity, which has caused upgrade issues (the “libgit2 issue”), various issues around the Java stack, including the broken eclipse packages in fedora 31+ and the “forced move” to modules (or even the recommendation to use the flatpak version instead), and so on. I’ve been actively working to keep the non-modular Java stack maintained under the umbrella of the Stewardship SIG, so packagers who can’t (or won’t) move their packages into modules don’t suffer from this current, broken situation.

What objectives or goals should FESCo focus on to help keep Fedora on the cutting edge of open source development?

With stagnating contributor numbers and an ever growing package base, I think the most important thing to tackle is making the packager workflow more streamlined. I already see progress being made into the right direction here (for example, making package un-orphaning a push-button action in pagure instead of having to go through a releng ticket manually). This both makes working on fedora packages easier for existing maintainers, and should make fedora a more attractive, modern project to contribute to for newcomers. The multi-build update workflow for rawhide with on-demand side-tags also seems like a good improvement, both for packagers, and for the stability of rawhide. I think a gating check that rejects packages which introduce broken dependencies into the repository would be a good addition, as well (and it might help reduce the number of broken dependencies over time).

Improvements in this area directly benefits the stability of fedora and the ability of packagers to deliver new features faster – which means fedora can continue to be the best platform for developers.

What are the areas of the distribution and our processes that, in your opinion, need improvement the most? Do you have any ideas how FESCo would be able to help in those “trouble spots”?

I see a lot of issues surrounding Modularity (both regarding policy and implementation), but that topic has already sparked more debates than any other change in fedora since I joined a few years ago, so let’s not focus on that for now 😉

Other than that, I see the large (and growing) number of packages with broken dependencies as a big issue, and a sign that the fedora repositories aren’t in a great state – not even mentioning the fact that dependencies that aren’t satisfiable from the official repos might pose a legal risk for fedora, as well.

I think the updated FTBFS and Non-responsive maintainer processes already help here, since they make the problem of broken packages more visible for dependent packagers, and introduce an automatic cleanup of packages that fail to build and that nobody cares about.

Another area that I sometimes find a bit lacking is documentation for some common tasks (like getting a package’s dependency tree, or querying things that need to be rebuilt in case of ABI changes, …). While there is documentation and policy covering these tasks, it might be good to give concrete examples for correctly determining the impact of a change. This might also help to reduce the number of broken updates (and surprise SONAME bumps) in fedora, making development of rawhide more stable and predictable.