Author: Matthew Miller (page 2 of 3)

Fedora Council and the future of Modularity

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.

Continue reading

Let’s keep writing a new vision statement for Fedora

Last month, I shared a draft vision statement that the Fedora Council worked on during our face-to-face meeting in November. We got a lot of great feedback on the council-discuss list. When the Fedora Council met after DevConf.CZ, we went over the feedback and came up with a new draft:

The Fedora Project envisions a world where everyone benefits from free and open source software built by inclusive, welcoming, and open-minded communities.

Continue reading

Fedora Council November 2019 meeting: more miscellaneous stuff

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

In addition to the big topic of the Fedora Project Vision, we used the opportunity to cover some other Fedora Council business. Because it’s a lot, we’re breaking the reporting on this into two posts, kind of arbitrarily — here’s the second of those.

Continue reading

Fedora Council November 2019 meeting: Councily business

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

In addition to the big topic of the Fedora Project Vision, we used the opportunity to cover some other Fedora Council business. Because it’s a lot, we’re breaking the reporting on this into two posts, kind of arbitrarily — here’s the first of those.

Continue reading

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 booth at Red Hat Summit

Red Hat Summit — the annual conference for Red Hat customers, partners, and open source contributors — took place last month in Boston, Massachusetts. Fedora had space in the Community Central booth on the expo floor and we had a lot of great conversations with our community.

Continue reading

Fedora BoF at Red Hat Summit

Every year, Red Hat holds a conference for customers, partners, and open source contributors — Red Hat Summit.This year’s was last month, in Boston, Massachusetts, and of course Fedora was there. We had our booth in the “Community Central” area of the expo floor, and ran a birds-of-a-feather (BoF) session for open discussion with community members. I was joined by Brian Exelbierd, Ben Cotton, Adam Šamalík, and a dozen members of the Fedora community.

Continue reading

Flock Talk & Session Proposal Reminder

It’s hard for me to believe, but it’s been more than five years since we launched the “Fedora.next” initiative. At the end of Fedora’s first decade, we knew it would be important to think, plan, and adjust so the project could continue successfully in the decades to come. Now we’re halfway into the next one, and this Flock conference will be an important time for reflecting on our progress and charting our path for the next five years and beyond.

Because Flock is focused specifically at our contributors and developers, this is a unique conference and we’re looking for talks and sessions that reflect that.

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.

Olderposts Newerposts

Copyright © 2021 Fedora Community Blog

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

Theme by Anders NorenUp ↑