This post is part of an FAQ series about the updated strategic direction published by the Fedora Council.
The Council’s updated strategic direction guidance is intentionally high-level, which means you probably have a lot of questions about what it actually means for you. If you’re a Fedora packager or a software developer, here’s some more concrete answers.
What does this mean for Packagers and other groups like them?
Packagers remain free to provide software at the versions and cadence they wish. However, that doesn’t mean they can block others providing the same software in different versions and cadence. For example, if you only want to work on the very latest version of a particular piece of software as it comes from upstream, that’s cool — but you have to leave room for someone else who wants to maintaining older releases of that same software.
This isn’t necessarily new — we’ve seen this with, for example, co-maintainers where one person works on the main Fedora OS package and someone else maintains an EPEL branch. But this goes further with features and even bugs. Perhaps a Fedora solution like CoreOS or the Fedora KDE Plasma desktop needs a slightly different version than the “main” one to enable (or strip down) some particular feature. That’s okay! We have multiple stream branches to allow this.
The same is true for changes and other ideas, including greater automation in packaging. Perhaps someone wants to provide a stream where updates are automatically triggered when upstream makes a release. Or maybe someone wants to try out a whole new way of generating specfiles from templates. We don’t block people out, instead we provide options. There is no obligation for packagers or others to provide all possible options, but we also don’t want to restrict those options from being provided by someone who is interested.
What does this mean for software developers?
Software developers will be able to use Fedora to develop software by selecting the building blocks that make their development environment. These development environments are essentially highly-tailored solutions with extremely specific applicability. Additionally, the output of software development is a building block that other solutions can use.
Ideally, Fedora becomes the reference architecture for the next generation of software development. More flexibility in package branches will make that possible — if what we have isn’t a perfect match, there can be options within the project rather than requiring people to instead look elsewhere.
February 17, 2019 — 16:39
This FAQ was helpful and clear to me. This lets people be bold to try out new Solutions and ideas without a lot of red tape blocking them. It allows for a democratization of ideas too. I do wonder how some of these examples will work in practice though, for example if someone wants to release an older or newer release of an existing package, independent of its current maintainer. What does that process look like?
February 21, 2019 — 20:45
Right now, it means that you’ll need to be a co-maintainer of the package, which is generally something which the existing maintainer (package admin) can grant. I think that in most cases, people can collaborate well enough that even if they don’t care about what the other person is doing they’ll be happy to grant access to do it. If we get into situations where we need something more … complex than that, hopefully this post will help guide implementation of more specific policies.