User:Bkearney/ProposedSpinProcess

This page is a draft only
It is still under construction and content may change. Do not rely on the information on this page.

Overview

Having just gone through the process, there are lots of folks willing to help you through creating a spin. However, it is not the most straight forward. Here is my cut of what I think it should be. Assuming the new trademark guidelines are in place this would be a process for officially hosted spins. Much of this doc was edited from the existing process SIGs/Spins/SpinSubmissionProcess here.

Requirements

For this process to work, the following must be defined

• New Trademark Guidelines
• Resolution on if the SPINS SIG will carry all spins, or just Hosted SPINS (This process assumes hosted)
• The board must define a written MINIMAL REQUIRED TECHNICAL SPECIFICATION to something to be called a Fedora Distribution (e.g. SELinux must be enabled)

Submission Process

This process is designed to be linear. Most of the technical review is front loaded on the SPIN SIG, so that the latter steps are streamlined as much as possible.

Step 0: Is this a spin?

If all of these are true, then continue on with the process

1. You have a spin concept you would like to be included in the Kickstart Pool and hosted on [[1]]
2. It complies with the Spin Guidelines
3. It complies with the Community Spin Guidelines
4. It complies with the MINIMAL REQUIRED TECHNICAL SPECIFICATIONs

Step 1: Define the Spin as a Feature

Every Fedora release, define a Feature Page for the spin. If this is a subsequent release, the summary page can be a copy of the previous release. The feature page should include:

1. A description of the spin concept. Here's a couple of ideas:
   • Does it have a particular target audience?
     • Grannies in church need bigger font sizes
   • Does it have a particular use(-case)?
     • I boot this specific spin on XXX desktops at the office so that (...)
   • Is it a localized spin (based on an existing spin)?
2. The spin concept's scope:
   • Does the spin concept apply for being officially released?
   • Does the spin concept need to be included in the Kickstart Pool package (being released, as a package, via Fedora repositories)?
   • Is the spin going to be maintained during it's lifecycle? The lifecycle of a spin is at least one Fedora releases lifecycle.
   • Does the spin expect to release updates during it's lifecycle?

Step 2: Gain Approval for Spin from the Spin SIG

The Spin SIG owns this step. The goal of this step is for the SIG to ensure that the evaluation which you made in Step 0 is accurate. In theory, the only thing which should keep the SPIN from not being included after this step concludes is either Trademark issues (brought up by the board) or capacity issues by release engineering.

1. If you have not done so, join the Spin SIG [| mailing list]
2. If this is the initial spin submission, email the group the proposed kickstart file
3. if this is a subsequent spin submission, email the group the link to the kickstart file in the the GIT Repository
4. In both cases, the submission email and the kickstart file should follow the submission guidelines below
5. Iterations are done via email
6. Once approved, the submitter should request access to the Spins GIT Group.
7. The submitter can then edit the kickstart file, and commit changes as necessary.
8. Any subsequent changes should be communicated back to the SIG via the mailing list.

Submission Guidelines

When submitting a spin concept, the first thing you do is debranding the spin. To the kickstart file for your spin concept, you add:

%packages
-fedora-logos
generic-logos
%end

and:

%post
sed -i -e 's/Fedora/Generic/g' /etc/fedora-release
%end

In your submission email to the Spin SIG mailing list, you should include:

1. A link to the spins Feature page.
2. The kickstart file you want to add to the pool.
   • Make sure it has a brief description of the spin's purpose on top, and the author(s)/maintainer(s). Check the GIT Repository for examples.
3. The SIG's name (if any) involved with developing and maintaining the spin concept, and/or your FAS account name
4. If applicable, an description of changes you apply that are not covered with the Community Spin Guidelines , such as:
   • The reason for changing the default behavior of an application
   • Excluding or including packages for a localized spin because the spin breaks with or without that specific package (include Red Hat Bugzilla bugnumber)