News and updates for about the Fedora Project community that develops supports and promotes Fedora. For more information, and to download the Fedora OS head to Get Fedora. For general news about the Fedora OS, check out the Fedora Magazine

What does Factory 2.0 mean for Modularity?

This blog now has a drop-down category called Modularity. But, many arteries of Modularity lead into a project called Factory 2.0. These two are, in fact, pretty much inseparable. In this post, we’ll talk about the 5 problems that need to be solved before Modularity can really live.

The origins of Factory 2.0 go back a few years, when Matthew Miller started the conversation at Flock. The first suggested names were “Fedora Rings”, “Envs and Stacks”, and Alephs.

What problems did Factory 2.0 want to solve?

#1 Repetitive human intervention makes the pipeline slow.
#2 Unnecessary serialization makes the pipeline slow.
#3 The pipeline imposes a rigid and inflexible cadence on products.
#4 The pipeline makes assumptions about the content being shipped.
#5 The distro is defined by packages, not “features” (Modularity).
#6 There’s no easy way to trace deps from upstream to product.


The great news is… if we had problems before, they’re about to get a lot worse. Does the Lego analogy say anything to you? This is how Modularity would look like without Factory 2.0.

What Factory 2.0 is not

Factory 2.0 is not a single web application.

Factory 2.0 is not a rewrite of our entire pipeline.

Factory 2.0 is not a silver bullet.

Factory 2.0 is not a silver platter.

Factory 2.0 is not just Modularity.

Factory 2.0 is not going to be easy.

Does Modularity mean anything with Factory 2?

Does Factory 2 mean anything without Modularity?

Problem Number 1: Automating Throughput

Repetitive human intervention makes the pipeline slow. This one can cover a lot of ground: Rebuild automation, compose automation, release automation.

Rebuilds and Composes

Builds: For this we’d like to build a workflow layer on top of koji called “the orchestrator” (or, the build orchestrator). The concept was originally confused with modularity-specific considerations, but we’d like it to be more general.


Take pungi and break it out into an ad hoc process alongside the buildsystem.

In the best scenario, compose artifacts are built before we ask for them.


We can do two-week Fedora Atomic Host releases now. Hooray!


Can we reconcile that with the mainline compose/QA/release process? The problem is much more intense for Red Hat just due to volume. We have uncovered ground in Bodhi for automation. The karma system is a predecessor, but it relies on humans. Can we fast-track some components based on Taskotron results?

How can we specify an (automated) policy for setting difference release cadences? (without hard coding it)

Problem Number 2: Pipeline Serialization

Unnecessary serialization makes the pipeline slow. This is less a problem for Fedora’s Infrastructure than it is for the Red Hat-internal PnT DevOps environment: things happen, unnecessarily, in serial. One big piece we (will) share here is the Openshift Build Service (OSBS) for building containers. We’re going to need to crack the nut to get around new problems (assuming we “go big” with containers).

Internally, we’re going to be using a special build key for this — which we’ll treat as semantically different from the gold key. Let’s consider doing the same in Fedora.

Problem Number 3: Flexible Cadence

The pipeline imposes a rigid and inflexible cadence on “products”.


Related to the previous point about Automating Releases. In the first analysis, “the pipeline is as fast as the pipeline is.”


Think about the different EOL discussions for the different Editions. Beyond that – a major goal of modularity is “independent lifecycles”. What does that mean in practice?

Let’s talk about pkgdb2 and its collections model.

Problem Number 4: Artifact Assumptions

The pipeline makes assumptions about the content being shipped. Remember we asked some Red Hat stakeholders what they wanted out of a next generation pipeline? There were some real gems in there. My favorite was: “I want to be able to build any content, in any format, without changing anything.”

This is fine


This one is an odd duck among the problem statements. Qualitative – not quantitative. Do we have to do gymnastics every time we add a new format? Or can we make that easier over time?

Autocloud and two week atomic, OSBS, Flatpak, snaps, rocket containers, etc… We can do anything. But how easily can we do it? Which leads us to….

The pernicious hobgoblin of technical debt: Microservices (consolidate around responsibility!), reactive services, idempotent services, infrastructure automation…

Problem number 5: Modularity

All Roads Lead to Rome. The distro is defined by packages, not “features”. There are some specific things about modularity (module build service, BPO, etc…). Really, this is where we tie all the threads together. Each has a certain value on its own, but if we can’t “do modularity” it won’t have the same effect.

Building modules


See the Modularity Infrastructure page. Then, visit the dev instance of the build pipeline overview app.

Problem Number 6: Dependency Chain

There’s no easy way to trace deps from upstream to product (through all intermediaries).

We can model deps of RPMs today, kinda. We can model deps of docker containers in OSBS.

Productmd manifests produced from pungi contain the deps of all our images. So, that’s great. But there’s no easy way to traverse deps all the way from upstream component to end artifacts.

Let’s expand pdc-updater.


And then we can use that data for great justice. 


There’s an opportunity to do something very cool with how we make the distro. Please tell us where we’re wrong. Hop in #fedora-modularity and #fedora-admin to join the party.

The so-called “Factory 2.0”

Presented at Flock 2016 by @ralphbean.

Slides available at

Fedora 25 Supplementary Wallpapers: Vote now!

At the end of August, the submission phase for Fedora 25 Supplementary Wallpapers opened. Now, the submission phase closed and the voting phase is now open. If you have a FAS account and meet the CLA+1 group requirement, you can cast your vote in Nuancier.

Wallpapers for Fedora 25

We have 113 contributions from 80 different contributors and awarded 73 badges for submissions. This compares to 124 valid submissions from Fedora 24. In case your badge was not awarded, ping gnokii in #fedora-design on freenode.

As for past contests, a lot of the participants made their first contribution to Fedora. We will continue to improve Nuancier and the submission process for supplementary wallpapers. We will also try to improve quality of submissions. We already improved with limiting the amount of submissions. We also had longer phases for submissions and the time for the voting is also longer as before.

Be sure to cast your vote before October 23rd, 2016 to have a say in what wallpapers are included! By participating, you can also receive a limited edition badge too.

FUDCon LATAM 2016 starts today!

FUDCon is the Fedora Users and Developers Conference. The Fedora community holds this event annually in the APAC and LATAM regions since 2005. They became exclusive to APAC and LATAM in 2013 when the EMEA and NA regions began organizing the annual Flock conference.

What is FUDCon?

FUDCon consists of sessions, talks, workshops, and hackfests. For Fedora contributors, it is a unique opportunity to share experiences and work together on common goals for the region. For users, it is an opportunity to come into contact with Fedora contributors in the region. It helps find ways to collaborate with contributors and integrate into the community. For FUDCon LATAM, this helps the growth of the Latin-American community. The 2016 edition of FUDCon LATAM is being held from 13-16 October 2016 at Universidad Nacional del Altiplano in Puno. Puno is in southeastern Peru, on the shore of Lake Titicaca.

See you in Puno!

The Fedora community in Peru is one on the biggest in the region. Peru was the venue for FUDCon LATAM 2013 in Cusco. In 2013, FUDCon LATAM had the biggest audience in almost 10 years of FUDCons (around of 800  people attended the event).  We hope this event will help bring new partners to the Fedora Project!

Wayland By Default Test Day 2016-10-13

Today, Thursday, 2016-10-13, is the Wayland by Default Test Day! As part of this planned Change for Fedora 25, we need your help to test Wayland by Default! Using Wayland instead of X gives a better basis for isolating applications from each other and the rest of the system.

testdaywaylandWhy test Wayland By Default?

Systems using certain graphics hardware or graphics drivers (matrox, qxl) may have problems running the Wayland session. In these (rare) cases, users may have to configure gdm to use X11 (although automatic fallback should work most of the time). If we don’t manage to close all the feature parity gaps entirely, users relying on those features may have to choose the X11-based session.

Continue reading

Outreachy with Fedora, Fall 2016

What is Outreachy?

GNOME Outreachy is a global program that offers historically underrepresented people of gender and race stipends to write code for several participating FOSS projects . Inspired by Google Summer Of Code, Outreachy offers participants hands-on internships for contributing to open source projects.

In 2016, the Outreachy internship dates are from December 6, 2016 to March 6, 2017. Participants work remotely from home while getting guidance from an assigned mentor and collaborating within their project’s community.

Why open source and Fedora?

Free and Open Source Software (FOSS) is software that gives the user the freedom to use, share, study, and improve it. FOSS contributors believe that this is the best way to develop software because it benefits society, creates a fun collaborative community around a project, and allows anyone to make creative changes that reach many people.

Fedora is participating in Outreachy 2016, with a goal to welcome underrepresented minorities to contribute to the project.  Fedora mentors Outreachy interns and helps them get a hands-on experience with developing for an open source project.

Continue reading

FOSS Wave: Bangalore at UVCE

FOSS Wave - Bangalore, India: Standing in front of University Visvesvaraya College of Engineering

Standing in front of University Visvesvaraya College of Engineering preparing for the FOSS Wave event

It was another lazy Saturday with a rare sight of empty Bangalore roads. This FOSS Wave event in Bangalore had been in planning for almost a month. Finally, here we were on September 10th, 2016 in front of the almost a century old structure of University Visvesvaraya College of Engineering.

Five speakers reached the venue by 9:30am. We were to talk in two different sessions starting from 10:30am until 4:00pm on the following topics.

  • FOSS, its philosophy, ethics and importance
  • Fedora and contributing to the Fedora Project
  • Eminent women in the history of tech and FOSS
  • Basics of git and GitHub

Continue reading

FOSS Wave: Goa, India

This post details how we executed planned activities for Internet of Things (IoT) in Goa, India. First, thanks to Espressotive (headed by Sudhir Shetty and CIBA) for doing all the prep work from registration to our accommodation. Over a span of three days, more than 400 students from three colleges and universities attended the event.

Continue reading

AppData content ratings for games shipped in Fedora

GNOME Software developer Richard Hughes recently e-mailed the Fedora developers mailing requesting Fedora package maintainers to update their AppData files to include age ratings using OARS.

“The latest feature we want to support upstream is age classifications
for games. I’ve asked all the maintainers listed in the various
upstream AppData files (using the update contact email address) to
generate some OARS metadata and add it to the .appdata.xml file, but
of course some AppData files do not have any contact details and so
they got missed. I’m including this email here as I know some AppData
files are included in the various downstream spec files by Fedora
packagers. Generating metadata is really as simple as visiting then answering about 20 questions with
multiple choice answers, then pasting the output inside the
<component> tag.

Using the <content_rating> tag means we can show games with an
appropriate age rating depending on the country of the end user. If
you have any comments about the questions on the OARS page please do
let me know. Before the pitchforks start being sharpened it’s an
anti-goal of the whole system to in any way filter the output of
search results dependent on age. The provided metadata is only used in
an informational way.”

If your package ships an AppData file, please consider updating it. If you have any queries about the addition or OARS, please discuss it on the Fedora developers mailing list.

HackMIT meets Fedora

HackMIT is the annual hackathon event organized by students at the Massachusetts Institute of Technology in Cambridge, Massachusetts. HackMIT 2016 took place on September 17th and 18th, 2016. This year, the Fedora Project partnered with Red Hat as sponsors for the hackathon. Fedora Ambassadors Charles Profitt and Justin W. Flory attended to represent the project and help mentor top students from around the country in a weekend of learning and competitive hacking. Fedora engaged with a new audience of students from various universities across America and even the globe.

Continue reading

Heroes of Fedora (HoF) – F25 Alpha

Heroes of Fedora is back

Heroes of Fedora is back! This time for F25 Alpha.

Hello, and welcome to the Heroes of Fedora: F25 Alpha edition! Heroes of Fedora is written so that the quality of any release can be quickly surveyed by viewing the stats regarding tests performed on that release, such as Bodhi updates, Bugzilla reports, and release validation testing. In this case, we’ll be looking at F25 Alpha, so let’s get right to it!

Continue reading

« Older posts

Copyright © 2016 Fedora Community Blog

Theme by Anders NorenUp ↑