Here’s your report of what has happened in Fedora Program Management this week.
I’ve set up weekly office hours in #fedora-meeting-1. Drop by if you have any questions or comments about the schedule, Changes, elections, or anything else.
Continue readingThis post is part of an FAQ series about the updated strategic direction published by the Fedora Council.
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.
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.
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.
Here’s your report of what has happened in Fedora Program Management this week.
I’ve set up weekly office hours in #fedora-meeting-1. Drop by if you have any questions or comments about the schedule, Changes, elections, or anything else.
Continue readingMost of the Community Platform Engineering (CPE) team met in person last month in Brno during a week. CPE team is the team at Red Hat that works on Fedora and CentOS infrastructure. As a distributed team, we usually use DevConf.cz as an opportunity to meet face to face.
This is an update on what we have been up to during this week.
Continue readingIt’s almost time for me to submit the Fedora 31 schedule to FESCo for approval. Before I do that, I’m sharing it with the community for comment. After some discussion before the end of the year, we decided not to go with an extended development cycle for Fedora 31. After getting input from teams within Fedora, I have a draft schedule available.
Continue readingHere’s your report of what has happened in Fedora Program Management this week.
I’ve set up weekly office hours in #fedora-meeting-1. Drop by if you have any questions or comments about the schedule, Changes, elections, or anything else.
Fedora 30 includes a Change that will cause ambiguous python shebangs to error. A list of failing builds is available on Taskotron.
Fedora 30 includes a Change that will remove glibc langpacks from the buildroot. See the devel mailing list for more information and impacted packages.
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.
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.
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.
This week, the Fedora Badges team published a full walk-through of how to design new Fedora Badges on the Fedora Docs site. The walk-through is the best reference to use when designing new badges. It includes the following:
With some rather unfortunate delays is my report from last year’s Open Power Summit. Let’s dive in it, without further delay.
It took place between 3th and 4th October 2018 in Amsterdam, Netherlands. It is event organized by the Open Power Foundation, steward of the Open Power CPU ISA. It is open and builds on top of the heritage of the past Power architectures, enabling any vendor or individual to dive in to the technical deeps of it or even implement it on their own.
At the venue there have been booths of different foundation members and affiliated organizations. Like Raptor engineering with their Talos II and Blackbird platforms on showcase, Mellanox with accelerators cards, Yadro with big-data memory(RAM) dense servers or OpenCAPI consortium with bunch of accelerators from various manufacturers that are leveraging the OpenCAPI standard, just to note few. To add on the OpenCAPI it is open offspring of the CAPI that has been introduced by IBM with their Power8 architecture.
Here’s your report of what has happened in Fedora Program Management this week.
I’ve set up weekly office hours in #fedora-meeting-1. Drop by if you have any questions or comments about the schedule, Changes, elections, or anything else.
Continue readingCopyright © 2019 Fedora Community Blog
Theme by Anders Noren — Up ↑
Recent Comments