This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Thursday, December 6th and closes promptly at 23:59:59 UTC on Thursday, December 20th, 2018.
Interview with Fabio Valentini (decathorpe)
Describe some of the important technical issues you foresee affecting the Fedora community. What insight do you bring to these issues?
There’s been a lot of discussion about the compose (and release) process recently. While I don’t necessarily always agree with the motivation, I think improving the compose process would be crucial for the future. Speed is one measure, but it’s not the most important one in my opinion. I’d rather focus on making the process more reliable (and possibly even reproducible) to avoid issues like deliverables (possibly randomly) missing from composes (even the GOLD one, like what happened for fedora 29). I’d push for making the processes more reliable first, and optimize later (“premature optimization is the root of all evil”).
Another focus should be placed on how the Modularity effort is moving
forward. While I see big benefits in some areas, especially server
environments (I’ve read about efforts to make the different NodeJS
versions supported by upstream concurrently available as modules), I
don’t think it is suited for solving problems in the “desktop” use case,
since there are a lot more (indepentently) moving parts involved.
With respect to the “release cadence” discussion that has erupted
recently, I’d rather support a tick-tock cycle with annual “major”
releases (e.g. fedora 2019.0) and a “minor” release (e.g. fedora
2019.1), where effort for “major” changes isn’t constrained to 5 months,
but rather 11. Another possibility would be to just treat GNOME like
other packages and do updates during releases (like KDE), which would
make the “tock” minor releases unnecessary (many packagers already do
updates like this, GNOME is rather an exception here).
By extension, a modified release cadence like this would result in a
almost double the support period for major fedora releases (if we keep 2
major supported releases around, just like now), or reduce the number
of supported fedora releases by one (if we keep the support period the
same) – which other, recent discussions about the fedora release cadence
What objectives or goals should FESCo focus on to help keep Fedora on the cutting edge of open source development?
Since I don’t think that we can (or should!) “grow” fedora by
fundamentally changing what it means to be the linux distribution
“fedora”, I’d rather focus on improving upon the strengths fedora
- Continue to be a great platform to develop software on: Since
“developers and makers of any kind” are the core audience of fedora
Workstation, focusing on this area could make fedora not only a good,
but a better, or even an excellent choice for software developers.
- Continue delivering updated software stacks in a stable manner: GCC,
python, ruby, golang, etc. all make up a compelling development
environment. This probably means that a “development base” containing
the latest stable versions of these components would have to be released
at least anually – which is why I think the idea of a true “fedora LTS”
is a contradiction in terms. Fedora is supposed to be first,
after all. However, an argument for moving “major” (development)
platform updates to an annual cycle could be the possibly longer support
window for major releases, since “minor” updates wouldn’t obsolete the
“core development platform”. This would also benefit server deliverables
due to the possibly longer support window for the stable “core”.
- Continue making upgrades to new fedora releases as painless as they
are now: Maybe “upgrades” can even be treated as “big updates” one day,
bringing even more people up-to-date, and delivering more features first
We all know that the development and release model of fedora has its
drawbacks, too. Improving upon the “pain points” would be my preferred
way forward, instead of throwing everything that alread works out the
window. After all, the current model has served us well for many ears.
- Reduce likelihood of compose and release issues: (Automated) update
gating for rawhide; improved enforcement (and/or automation) of rules
around SONAME bumps/API and ABI breaks/mass rebuilds.
- Possibly adapt the release schedule: Development and release
engineering resources could be allocated more efficiently to the areas
that really need attention, instead of just putting out the latest fire
This could possibly mean moving to ONE annual release (I’d
only agree with this if more components would be updated mid-release,
for example GNOME), or moving to a tick-tock “major”-“minor” release
cycle with one annual “major” release – to pick up updated language
toolchains and make infrastructure changes – and one (or more?) “minor”
release(s) to update things atop this stable “core”. I don’t think we
need modularity for this, since only one set of packages would be
supported to run on a “major release” at a time.
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 think an area that could really be improved is the way some changes
(be it “Changes” or major package updates being pushed) are introduced
to fedora. For example, I find it hilarous that every release there’s a
need for a GNOME mega-update and a corresponding freeze exception, just
because the release schedules don’t match up. Moving the target date for
a fedora release to avoid situations like this could even reduce
release date postponements (which has improved over the years, but it’s
still kind of a meme that fedora never releases on time).
I’d also suggest being more conservative with accepting changes – I’d
like to see more testing before something big lands in rawhide (e.g.
dbus-broker transition, redhat-rpm-macros changes for build flags,
macros, etc.). Update gating can help with that, doing test rebuilds in
koji side tags (and maybe even test composes for the biggest changes)
could help too. Related to this, I’d also promote the usage of koschei,
and just add all existing packages to be tracked automatically. I’ve
already caught multiple issues by relying on koschei for my packages,
and I’m always surprised by how small the number of tracked “core”
I also increasingly see some packages (mostly
podman/buildah/runc/etc.) basically using fedora rawhide as their CI
system with bot-created snapshot builds being submitted to koji. While I
didn’t find a policy that explicitly disallows this, I think it’s
against the spirit of the Updates Policy, even for rawhide – since
there’s no way that automatically submitted builds can be verified to
conform the Updates Policy criteria. For example, “don’t push clearly
broken builds”, or “announce API/ABI changes a week in advance” just
isn’t satisfiable with bot-submitted snapshot builds. To reduce the
likelihood of broken packages in fedora, I’d amend the Updates Policy to
explicitly state that – basically – “rawhide isn’t a CI system”. (This
point doesn’t apply to GCC, glibc, and kernel snapshots though – they
are already explicitly allowed, and they are submitted by a human who
knows very well what they are doing.)