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)
- Fedora Account: decathorpe
- IRC: decathorpe (found in #fedora-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?
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 have mentioned.
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 already has:
- 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 faster.
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 (again).
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” packages is.
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.)