Fedora.next/boardproposal

From FedoraProject

< Fedora.next(Difference between revisions)
Jump to: navigation, search
(Add post-approval responsibilities.)
Line 70: Line 70:
 
* '''Environments &amp; Software Stacks Working Group'''
 
* '''Environments &amp; Software Stacks Working Group'''
  
= Conclusion =
+
= Post-Approval Responsibilities =
  
WRITE CONCLUSION
+
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 produce a charter and elect their initial membership.
 +
 
 +
== Product Working Groups ==
 +
First responsibility of the working groups will be to establish a governance charter for their working group and elect an initial membership. The first required deliverable of this group will be a Product Requirements Document. This document will be presented to the Board for ratification
 +
 
 +
The second deliverable should be a timeline for developing the first release of the product, along with identifying potential resourcing issues and necessary changes from existing Fedora procedures. This document will be presented to FESCo for ratification.
 +
 
 +
== 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.

Revision as of 17:41, 22 August 2013

NOTE: this is a preliminary draft and likely to undergo significant change


Contents

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 operating systems: Fedora Workstation, Fedora Server, and Fedora Cloud. These will inform our overall planning and marketing of Fedora, and guide our allocation of resources. The following targets and purposes are the initial guiding statements; fully-developed versions will be the first deliverables for product working groups as described below.

Fedora Workstation

  • Target audience: Linux users who want to be running Linux; developers, sysadmins and other IT professionals; Linux enthusiasts at universities; "makers" and content creators.
  • Purpose: Keep Linux users on Fedora and attract new users in this niche.

The traditional desktop is a shrinking market, as more general users move to mobile platforms. Even if we change our software, Fedora is not well-positioned to attack the tablet or phone-computing markets. However, there will continue to be users who require or want a desktop operating system, and a significant portion of these technical users will want to run Linux. We recognize that this is and will always be a niche, but we want Fedora to serve this niche well.

Fedora Server

  • Target: People for whom RHEL and CentOS don't move fast enough; people who want to see and influence the future of RHEL.
  • Purpose: Fill space left by RHEL's slower refresh; build a better RHEL; engage customers in development of RHEL, OpenStack, and other emerging technologies.

Although many people and organization do run Fedora in production server environments, our messaging in this area has historically been terrible. Myths outnumber facts; having a specific Fedora Server product will allow us to better tell people about what we actually can offer, and to adjust that offering based on feedback from a user community which we serve poorly now.

It is not part of the immediate proposal, but we may want to explore a longer lifecycle for the Fedora Server product.

Fedora Cloud

  • Target: Development; DevOps in production; OpenShift
  • Purpose: Address emerging market which we do not currently cover well.

This product is a cloud guest image. It differs from Fedora Server in the need for hardware support, but beyond that, Fedora Cloud OS will also be the primary point for development of a system of pluggable software stacks. Separating from the Server OS allows us the freedom to address newer models for software deployment without getting in the way of more conservative requirements.

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

Defining the common base on which the Fedora OS products will be built.

Environments & Software Stacks

Develop and maintain 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.

Working Groups

Several working groups will be tasked with the practical next steps of this proposal.

In the existing Fedora terminology, SIGs are very informal, and may eventually graduate to "Projects", although most do not. Currently, Cloud, Desktop, and Server all have Fedora communities at the SIG level, at various levels of involvement. Going forward, we will create Project-level groups for the three products outlined above, with formalized objectives, membership, and governance.

Like the existing Fedora Packaging committee, each group will be an independent sub-committee of FESCo, with membership selected by FESCo from community volunteers, with at least one FESCo member in each to act as a liaison.

  • 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 produce a charter and elect their initial membership.

Product Working Groups

First responsibility of the working groups will be to establish a governance charter for their working group and elect an initial membership. The first required deliverable of this group will be a Product Requirements Document. This document will be presented to the Board for ratification

The second deliverable should be a timeline for developing the first release of the product, along with identifying potential resourcing issues and necessary changes from existing Fedora procedures. This document will be presented to FESCo for ratification.

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.