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

Since the “should we switch to systemd” discussion has finally settled down, few things have inspired passionate conversations on the devel mailing list like Fedora Modularity. Developing Modularity has been a long process and we finally shipped “Modularity for Everyone” in Fedora 29. But we know there are a lot of rough edges, and it’s not surprising that the response hasn’t been completely enthusiastic. Let’s be honest: we’ve ended up in a situation where a lot of Fedora developers hate Modularity.

The Council agrees that Modularity serves a purpose that we really want to see Fedora, but we also understand the community frustrations. The packager experience is difficult, and handling upgrades needs additional work. We don’t want to throw away the work that’s been done, we want to take what’s there and make it work better.

The Council agreed to three goals for Modularity:

• Users should have alternate streams of software available
• Alternate streams should be able to have different lifecycles
• Packaging an individual stream for multiple outputs should be easier than before

As the current Modularity Objective was ending, we wanted the next Objective to focus on “problems and papercuts”. It should make the packager experience good and fix the upgrade experience.

Since then, responsibility for Modularity development in Red Hat moved to a new team. This presents a good opportunity to reset opinions and start anew. As the new team gets their arms around Modularity, you can expect an updated Objective proposal that will improve Modularity for Fedora. On behalf of the entire Fedora Council, I want to thank Langdon White and everyone else who got Modularity this far. I’m looking forward to continuing to make it better.