Quick Summary
- Make three separate products (Fedora Workstation, Fedora Server, Fedora Cloud) to fit specific target needs as defined by the Fedora Project. Focus our planning, development, and marketing on these products, but also make it easier for community members to produce alternatives.
- Define a common core which these products and alternatives can rely on. Aim to provide interface stability to outer levels, while allowing well-coordinated progress.
- Make it easier for software to be part of the Fedora universe without being in one of the Fedora OS products or even in the distribution itself. Standards for software in "ring 2" may be less stringent and offer fewer guarantees.
Background
I hope everyone has seen my "Fedora Rings" talk as presented at Flock and discussed on the development list. This proposal combines those ideas for Fedora policy with a practical product strategy (originally from Stephen Gallagher, but like the rings idea, based on and refined through discussion with many others).
FESCo is interested in developing the practical implementation of these plans, and as they clearly involve strategic direction, we also want to make sure that the board is (um) on board. So, this proposal covers a brief technical introduction to our current plan, and describes a framework for building its practical implementation.
In that past, we have made Fedora from one big collection of packages all treated identically, except for additional QA coverage of "critical path" largely based around system installation. The previous attempt to define a "default user" and "default offering" became diluted by a pull to be all things to all people. That approach has not worked. Instead, we want to focus on three well-defined use cases, while also making the tools we use to build products for those cases available to other interests in the Fedora community.
Target Products
We propose that the current "default offering" be replaced with three distinct products: Fedora Workstation, Fedora Server, and Fedora Cloud. These will inform our overall planning and marketing of Fedora, and guide our allocation of resources.
Change to Primary Architecture Definition
Primary architectures must target at least one of the Fedora OS products, but do not need to produce all three. For example, an ARM cloud image does not yet make sense, and were s390 to be a primary arch, it might be server only. On the other side, we might drop 32-bit x86 server. Secondary architectures may just publish a collection of packages and not attempt to target any product at all.
Base Design
This is the common base on which the Fedora OS products will be built. Language stacks and environments will be able to assume that this is available and consistent across all of Fedora, and that change will be carefully managed.
The Fedora.next proposal suggests that this should exist, but leaves open exactly what it will look like. This group will create a reference document that answers that question, and work on the practical infrastructure for building this as a subset of Fedora.
Environments & Software Stacks
We will also develop policies for software in what will become "ring 2". Currently, the Fedora Packaging Guidelines apply to all software; we need guidelines for how software may be included under the Fedora umbrella without necessarily conforming. This group will create those guidelines and work to enable new ways of doing things on top of the Fedora base.
We want to allow disruptive innovation without disrupting what works in Fedora now; this group will help manage that. At first, work will be concerned with more conservative approaches like the first generation Software Collections (which may fit in with only minor exceptions to the current packaging guidelines), this is also the place to explore and solve issues like container composition and updates.
Working Groups
Working groups will be independent sub-committees of FESCo with membership selected by FESCo from community volunteers. The working groups will be tasked with the practical next steps of this proposal. There will be at least one FESCo member in each to act as a liaison. There should be a liaison with the QA, rel eng, docs, marketing, and web/infrastructure groups as well although these may not be people from those teams but people tasked with facilitating dialogue between those groups and the working group instead.
The Working Groups will have certain elements in common with the Fedora Packaging Committee and with the (currently inactive) Fedora Engineering Services group. They will be tasked with both creating policies and guidelines around their specific area and with implementing the tooling needed to fulfill those goals. Working groups will be empowered to make decisions independently within their areas; FESCo is responsible for resolving any issues which impact more than one target product.
These Working Groups may draw on the membership of existing SIGs (for instance, the Cloud Working Group may heavily utilize active people from the Cloud SIG to achieve their goals) but the role of SIGs in Fedora is a bit different than the Working Groups. SIGs are informal collections of people with a common interest who can discuss ad hoc issues together. The working groups are intended to be more focused on defining formal objectives for their areas and then achieving those goals.
The following Working Groups will be created:
- Product Working Groups
- Fedora Workstation
- Fedora Server
- Fedora Cloud
- Base Design Working Group
- Environments & Software Stacks Working Group
Post-Approval Responsibilities
If this proposal is approved by the Board, next steps will need to be taken by the following groups.
FESCo
FESCo will be responsible for facilitating the creation of the product-specific working groups, helping them to produce a charter and selecting their initial membership. FESCo will also will coordinate communication and scheduling between the working groups, and help resolve conflicts where necessary.
Product Working Groups
The first responsibility of each working group will be to establish a governance charter.
Then, the first required deliverable for each group will be a Product Requirements Document. This will include a statement of target audience and the role the product is intended to fill in the Fedora ecosystem. This document will be presented to the Board for ratification. These should be done by January, 2014.
The second deliverable should be a list of necessary changes from existing Fedora procedures needed to release the product. This should be ordered to show what things depend on other changes and at which point the changes will mean that we can no longer produce the current type of Fedora. This will allow us to identify the resources needed by what teams in order to implement the plan and at what point we may need to have a longer than normal release cycle to do tooling work.
The last deliverable is to actually start producing the Fedora Products listed here. The list of necessary changes generated as the second deliverable describe the intermediate steps to achieve that goal.
Release Engineering
Release engineering's first deliverable will be a high-level overview of tooling changes needed to deliver these new products, as well as to identify potential resourcing issues.
QA
Fedora QA's first deliverable will be to work with each of the Product Working Groups to define a set of Release Criteria appropriate for that product. The proposal should include any resource issues around testing and automation.
Websites
The "Get Fedora" website will need significant redesign. We will also want landing pages and brochure site for each of the Fedora products.
Documentation
We will need a plan for how documentation is and is not shared between products. Each product will certainly have at least some amount of individual documentation. Other documentation may need to be updated to clarify target audience and platform expectations.
Marketing
This represents a significant shift in marketing strategy. Marketing each Fedora product independently is fundamental to the proposal, and a plan for doing that marketing will need to be developed.