This post shares two new proposals for changes to Fedora Council policy.Continue reading
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.
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 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.
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:
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.
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.
In December, the Fedora Council met in Minneapolis, Minnesota for several days of meetings. With the holidays now behind us, here’s our summary of what happened.
The most important part of the meeting was our update to Fedora’s strategic direction. You may have read the Community Blog post about this already. While the wording — or at least the fact that we’ve written it down — may be new, the ideas aren’t. This document represents the next step from the efforts that began with Fedora.next back in 2013. Our goal is to allow members of the Fedora community to build solutions that focus on the specific requirements of their target users. This means, among other things, a more decomposed and self-service build process.
The earlier post generated a lot of discussion and feedback. I’m planning a series of Community Blog articles summarizing and responding to that feedback — stay tuned!
We also heard from three of the four current Objective leads. (Our Internet of Things lead, Peter Robinson couldn’t make the meeting, unfortunately.) The CI/CI Objective is wrapping up and Dominik Perpeet will be publishing a summary soon. The Modularity Objective is also ending its current phase. Modules for Everyone was a key feature of Fedora 29, and the Modularity team is continuing to improve the technical implementation as well as make it more approachable for community contributors. Both Objective leads will be proposing next steps to the Council in early 2019.
The Lifecycle Objective is just getting started. It has two goals: make the release process scale and allow & encourage more community ownership for deliverables. This ties in tightly to the strategy update — this work is required to get us to where we want to be. Paul Frields is working to gauge what’s needed to implement this now, including the proposed long cycle for Fedora 31 (discussed on the devel mailing list). The Council in general would prefer to keep to the regular six-month cycle.
The Mindshare team previously adopted a policy of spending up to $100 for release parties with minimal approval required. This has been successful, and the Council would like Mindshare to build on this with further investment. We agreed that Mindshare should adopt a policy of allowing up to $150 for activities that promote the use of Fedora solutions in communities. This could include release parties, web hosting, or other relevant activities. We want to encourage experimentation, so we’re not requiring the activities to be successful to get reimbursed — they just need to be successful to get future funding. The Council’s goal is to have 100 of these proposals funded in FY2020 (which starts in March of 2019). In order to encourage funding these proposals throughout the year, unallocated funds from this budget will be pulled into the Council budget at the end of each fiscal quarter. Look for guidance from Mindshare on how to make these requests soon.
We’ve started experimenting with using Discourse as the asynchronous communication tool for some teams. For synchronous communication, some teams are using Telegram in addition to — or instead of — IRC. Each platform has strengths and weaknesses. After discussion, the Council came to the conclusion that communication fragmentation is unavoidable. In a project as big as Fedora, people work in different ways and have different preferences. We leave it to each team to decide what communication methods work best for their team.
To help connect everyone together despite this, we have requested a central project management service from the Infrastructure team — probably Taiga, although we’re asking the team to also look at GitLab for this purpose. We’ll have a dedicated instance, likely hosted, and we ask each team to have a minimum presence on that tool, whether they use it otherwise or not. The presence should, at a minimum, indicate the team’s communication methods for synchronous and asynchronous communication and where project information may be found if not in the shared tool. That way, there will be an automatically-curated list of active teams. (See https://tree.taiga.io/discover for an idea of what this would look like — imagine each project there is a Fedora team.)
The success of our strategy depends on improvements to our infrastructure. The Infrastructure team has limited resources, so we need to ensure they’re able to work on areas that add the most value to the project. This means a shift away from running all layers of the stack and focusing more on application management. The goal is to have the Infra team administering applications, not low-level infrastructure. (Even if that makes the team name confusing — sorry!) We want agility in our applications and deployment. We want drive-by contributors to be able to realistically contribute to the infrastructure team.
We also talked about GitHub. Ideally, we want everything to be on open source services (e.g. Taiga, Pagure, or GitLab). But, as a pragmatic matter, we recognize that GitHub has a huge network effect — there are millions of users and developers there, and millions of open source and free software projects hosted there, including software that’s fundamental to the Fedora operating system. We’d like better integration and syncing with tools like Pagure to give access to that network effect on all-free software, but we also know that there isn’t a lot of developer time to make and maintain those kind of features. Therefore, we’re willing to accept people in Fedora hosting their subprojects on GitHub. We’ve got to focus on what we do that’s unique (and only do things which are unique when we have a special need to meet our project goals). Git hosting is not one of those things.
The Council wants to make it clear that community input is welcome on Council matters. Members of the Fedora community may provide non-binding votes on Council tickets and participate in meetings. Speaking of meetings, we’re replacing the Subproject report meetings with regular updates from the FESCo, Mindshare, and Diversity & Inclusion representatives. This should help provide better visibility into those organizations for the Council and the community at large.
We will also move all Council policies out of the wiki to docs.fedoraproject.org. The Council will use the wiki only as a scratch space for works in progress. Durable documentation will live on the docs site. We encourage other teams to consider doing the same.
We didn’t actually conduct the meeting in IRC, but we took minutes in the same way. Here’s our detailed record.
#startmeeting Fedora Council Hackfest 2018
#chair mattdm bcotton tyll contyk dperpeet langdon dgilmore bex jonatoni sumantro stickster
#topic Mission overview + Strategic framework
#info Community Members are encouraged to contribute to the decision process with non-binding votes
#info mattdm shows his favorite graph
#topic Fedora Project Strategy: “How do we make our mission real?”
#action Dominik will speak more loudly
#agreed Council will replace subproject report meetings with updates from FESCo, Mindshare, and D&I rep
#agreed Council adopts the strategy proposal (+9, 0, -0)
#action mattdm to post the strategy proposal to commblog
#agreed Council will make a final vote on the strategy proposal on 9 January 2019 (+8,0,0)
#topic Moving Council Policies to Docs
#agreed Council will move all Council policies and other durable Council documents from the Wiki to docs.fedoraproject.org and remove old wiki pages. (8,0,-0)
#info policies should be kept in a repo separate from other documents for ease of watching
#topic Objective Update: CI/CD
dperpeet to write up final objective report for publication on Community Blog by January 1
#action dperpeet to propose a new Objective for future CI/CD work
#info the new Objective should include working with other stakeholder groups including IoT and SilverBlue
#topic Objective Update: Modularity
#action langdon to propose a new Objective for future Modularity work
#topic Objective Update: Lifecycle
#topic $150 release parties
#agreed Mindshare should move the easy process to $150 and encourage more non-RP uses (+9,0,-0)
#agreed: Mindshare should start providing $150 base support for solutions to help them grow (+9,0,-0)
#agreed: Mindshare should start attracting larger requests and develop a process. These requests are judged using Council provided Fedora Project strategy as guidance. (+9,0,-0)
#agreed: Mindshare should target at least 100 $150 events in FY20 (+9,0,-0)
#agreed Unspent budget allocated to the $150 event program will be pulled into the Council budget at the end of each fiscal quarter beginning with FY20 (+10,0,-0)
#action bex to begin a conversation in the translation community about a platform that meets the needs of the translation workflow
#info Adam Miller will not get a tattoo with our current logo because people will ask him why he has a Facebook tattoo
#info The design team is working on getting a proposal to the community to vote soon so we can select the new one by January 31 in final form for production
#agreed The Council supports greater efficiency in the infrastructure to allow more to be done, even when this means that we move away from self-hosted or self-maintained infrastructure. (+9,0,-0)
#agreed The Fedora Project wants to advance free and open source software and as a pragmatic matter we recognize that some infrastructure needs may be best served by using closed source or non-free tools today. Therefore the Council is willing to accept closed source or non-free tools in Fedora’s infrastructure where free and open source tools are not viable or not available. (+9,0,-0)
#action contyk, FESCo to work with Infra to examine current applications and determine: 1. which applications can be moved out of the datacenter immediately or in the short term, 2. Which applications have industry-standard open source or proprietary alternatives that we could move to.
#agreed Fedora will offer a central place for teams and SIGs to be discoverable, do project management, etc. Having a landing page will be a requirement for all teams and SIGs in Fedora. (+10, 0, -0)
#agreed The Council will ask the Infrastructure team to evaluate providing the central place as Taiga versus Gitlab based on requirements provided by Council. (+10, 0, -0)
#action mattdm to write requirements doc for these two things above.
#agreed The Fedora Council embraces fragmentation in our communication platforms — this is a reality we can’t fight. The Central Place will provide a way for anyone to find the communication tools used by any group. (+10, 0, -0)
#topic Ticket #198
#agreed Document proposed in ticket #198 is accepted for delivery to Legal for drafting updates to the Trademark policy. (+10, 0, -0)
#topic Code of Conduct enforcement
#agreed The FCAIC is empowered to take action on Code of Conduct reports with an additional +1 from another core Council member or the Diversity & Inclusion Advisor and report back to Council. (+10, 0, -0)
#topic Ask Fedora and getting help
#agreed Council authorizes the hosting of a separate Discourse instance to replace ask.fedoraproject.org to be funded out of Fedora community budget. (+9, 0, 0)
The Fedora Council met last week in Minneapolis, Minnesota. It’s a lovely city, but rather cold, so we largely stayed within the interconnected network of enclosed bridges known as the Skyway — and in our conference room working. One of our main projects was the draft below. This is a follow-on from our update to the mission statement last year. It represents the way the Fedora Council would like the Project to make that mission a reality — a guiding policy. We’d like wider community feedback on this approach (and the write-up of it), after which we plan to include the final version in the project documentation.
— Matthew Miller, Fedora Project Leader
“Fedora creates an innovative platform for hardware, clouds, and containers that enables software developers and community members to build tailored solutions for their users.”
We do this within the context of the four foundations: freedom, friends, features, and first.Continue reading
Copyright © 2019 Fedora Community Blog
This work is licensed under a Creative Commons Attribution 4.0 International License.