Category: Council (page 1 of 2)

Sticky post

Let’s write a new vision statement for Fedora

This is part one of a four-part series recapping the Fedora Council’s face-to-face meeting in November 2019.

A few years ago, the Fedora Council set out to update the project’s guiding statements. At the time, we were particularly focused on the mission statement, because we felt that what we had previously was too broad to be actionable. The result of that is:

Fedora creates an innovative platform for hardware, clouds, and containers that enables software developers and community members to build tailored solutions for their users.

… which we quite like. But, this focus has somewhat of a downside: it’s functional but not particularly inspiring. It talks about what we’re doing, but not much about the why. So, this year, we worked on a new vision statement to serve as the proverbial “banner on a hilltop” that we can use to rally our existing community and to attract new contributors.

Continue reading

Fedora status updates: November 2019

Welcome to the monthly set of updates on key areas within Fedora. This update includes Fedora Council representatives, Fedora Editions, and Fedora Objectives. The content here is based on the weekly updates submitted to the Fedora Council, published to the project dashboard.

Continue reading

October 2019: Fedora status updates

Welcome to the monthly set of updates on key areas within Fedora. This update includes Fedora Council representatives, Fedora Editions, and Fedora Objectives. The content here is based on the weekly updates submitted to the Fedora Council, published to the project dashboard.

Mindshare committee

So far this year, the Mindshare committee has approved all 12 event requests that have been filed. Three requests for swag-only have been approved. The community is reminded that Mindshare is there to help fund events and they can only do that if they’re asked.

On a related note, Sumantro Mukherjee published a Community Blog post calling for Fedora 31 release parties. Fedora 31 is scheduled for release later this month, so now is a good time to start planning release parties.

Google Summer of Code (GSoC) and Outreachy were completed successfully. The Mindshare committee is working on combining GSoC, Outreachy, and Google Code-In efforts under a single “mentored projects” umbrella.

Minimization objective

In the past month, the Minimization team brought the “feedback pipeline” to life. Feedback Pipeline gives a quick overview of the use cases we’re targeting to minimize. It shows required packages, their dependencies, the overall size, and allows a deeper inspection with interactive dependency graphs. As part of that work, the team is working on identifying use cases to target.

The Council approved the Minimization objective on a short-term basis. Adam Šamalík will be submitting a proposal for the next phase of this objective to the Council soon.

Fedora Silverblue

The Silverblue team is working on Fedora Flatpak preinstallation. Some patches are pending into the Fedora infrastructure to help enable this. The goal is to have the same preinstalled applications as Fedora Workstation.

In addition, planning for Fedora 32 Silverblue is underway. The team has a Kanban board available to the community.

Renewing the Modularity objective

Now that Modularity is available for all Fedora variants, it’s time to address issues discovered and improve the experience for packagers and users. The Modularity team identified a number of projects that will improve the usefulness of Modularity and the experience of creating modules for packagers. We are proposing a renewed objective to the Fedora Council.

You can read the updated objective in pull request #61. Please provide feedback there or on the devel mailing list. The Council will vote on this in two weeks.

September 2019: Fedora status updates

Welcome to the first of a monthly set of updates on key areas within Fedora. This update includes Fedora Council representatives, Fedora Editions, and Fedora Objectives. The content here is based on the weekly updates submitted to the Fedora Council, published to the project dashboard.

Continue reading

Council policy proposal: modify election eligibility

Inspired by the request that we provide written guidance on time commitment expectations and some conversations from our meeting in December, I have submitted a pull request to implement a policy that anyone running for an elected Fedora Council seat not run for other elected boards at the same time:

The reasoning is that we have an unspoken (for now) expectation that being on the Council, particularly as an elected representative, will not be a trivial commitment. This is an easier check than trying to determine post-election which body a candidate would rather serve on (and thus having to deal with alternates, etc).

Please discuss this on the council-discuss mailing list. Per the Council policy change policy, this will be submitted for a Council vote in two weeks.

Two new policy proposals

This post shares two new proposals for changes to Fedora Council policy.

Continue reading

Fedora Strategy FAQ Part 3: What does this mean for Fedora releases?

This post is part of an FAQ series about the updated strategic direction published by the Fedora Council.

What does it mean to “release Fedora”?

Fedora operating system releases are (largely) time-based activity where a new base operating system (kernel, libraries, compilers) is built and tested against our Editions for functionality.  This provides a new source for solutions to be built on. The base operating systems may continue to be maintained on the current 13 month life cycle — or services that extend that period may be provided in the future.  A solution is never obligated to build against all currently maintained bases.

What does this mean for today’s Editions, Labs and Spins?

We are not moving your cheese. At least, not very far. Today’s outputs are essentially unaffected, except in being granted more freedom.  It becomes easier for these solutions to release on their own cadence and to provide alternative software (which could be consumed by other solutions) to meet their users’ needs. We may want to release (for example) Fedora CoreOS completely separately from the base OS refresh, and have a marketing splash entirely around that solution and what the new release does for its target audience.

Labs and Spins are no longer required to be named as such — within the project, they are “Solutions”. (If you like the term “Lab” or “Spin” for something you’re making, feel free to keep calling it that!) These Solutions are “vertical” in that they consume various services to solve their target use case.  Solution builders are free to build their solutions on anything the Project has to offer that meets their needs.

Solutions may have access to different services based on criteria set by those vertical service providers, possibly following strategic guidance set by the Council or following recommendations from Mindshare.  For example, the Website Team support in the form of presentation on the main downloads page may be restricted to solutions with a large user base. Solutions with smaller user bases can grow their usage and gain access to this.

We are retaining the idea of Editions to denote those solutions we use as a test-gate for our releases.  These are our showcases that we will advertise heavily to users and use as a way of framing conversations about the project.

What about solutions that need long or short release cycles?

This is an area where we want the Fedora platform to shine. Modularity enables us to provide multiple versions of applications simultaneously, solutions can release frequently with what have traditionally been thought of as blocking upgrades. This means that these high-speed solutions can keep growing.

When a solution requires frequent changes to the base operating system to meet its need, the entire Fedora platform benefits.  These solutions can also be building block or service providers. Therefore if, for example, an IoT solution requires more frequent base library upgrades, another solution can also choose to use those rapidly updating base libraries as part of their build too.

Fedora Strategy FAQ Part 2: What does this mean for me?

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.

Fedora Strategy FAQ Part 1: What is Actually Changing?

This post is part of an FAQ series about the updated strategic direction published by the Fedora Council.

What is actually changing?

This strategy is an ideal we’d like the project to work towards, but it’s also a path that we’re already on. Some parts of this aren’t a change at all, but a clarification of the general consensus over the last few years.

Project Terminology and Teams

We want “Fedora” to be the Project. For things Fedora makes, we’ll describe them as “Fedora Thingname”, like “Fedora IoT” or “the Fedora RPM Package Collection”. I’ve been saying this for a while, but I want to make it official. (Just as “Red Hat” isn’t RHEL.)

We’re going to set up a hosted Taiga instance (more on this soon). Anyone in Fedora will be able to create a project there, and every team in Fedora should. This will create a directory listing which will supplant The Subprojects wiki page and have three significant advantages:

  1. Available all in one place
  2. Searchable in a reasonable, non-wiki way
  3. Not a wiki: inherently self-updating and sortable by activity

This is the minimum required to be a Fedora Team. Teams may have more formalized membership, a charter with rules for voting, regular meetings, regular reports to FESCo or Mindshare, etc. We decided against formalizing rules for words like “Working Group” or “Subproject” and instead agreed that any Team can use those labels if they like.

Teams providing services should formalize a menu of offerings. They should describe the criteria by which those offerings are provided. I think the Council should provide some standard ideas for reasonable criteria. These could include team structure and activity level, user base, a link to current Fedora Objective, etc.

More Autonomy

We need a way for Teams to release artifacts in a self-service way. The Astronomy spin (to pick a random example) should not need to wait for release engineering to make a release. In fact, they might choose to make new releases around the cadence of their most important included software. At the same time, since the Team can do it themselves, Release Engineering might also not be on the hook for building artifacts for spins with a niche audience or that don’t meet some other criteria.

We need to allow for non-RPM building blocks somehow. I mean, not in a technical way but in a rules way. We need to allow for RPMs built in non-traditional ways (the source git idea). No solution is forced to consume these, but we shouldn’t block someone from providing them, either. For example, Silverblue may want to provide some Flatpaks that are built (in an open and transparent from-source way) straight to Flatpak rather than going through RPM. Or AI/ML may want to generate and ship container images with python wheels built specially.


We need to relax policies on what Solutions are allowed to do. We also want to drop the Spins/Labs naming thing — it’s confusing to people even within the project. Solution-makers should know their audiences best and should be able to make more technical choices — the things currently known as Spins should be able to offer different defaults and presets, even including enabling different module streams by default. Solutions should not require Spin SIG (or FESCo) approval on technical merit or perceived feasibility.


We need to be able to adapt to the changing world without taking 18 months to do so each time.


Copyright © 2020 Fedora Community Blog

Creative Commons License
This work is licensed under a Creative Commons Attribution 4.0 International License.

Theme by Anders NorenUp ↑