From Fedora Project Wiki

< User:Bkearney

Revision as of 12:59, 12 September 2008 by Bkearney (talk | contribs) (→‎Submission Process)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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


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 understood process. Here is my cut of what I think it should be. This process would be applicable assuming the new trademark guidelines are in place and the spin is to be an officially hosted spin. Much of this doc was edited from the existing process, with the major additions being a better separation of duties. I think the current issues are around duty separation, and notifying release engineering.


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: Validate Spin Requirements

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
  2. It complies with the Spin Guidelines
  3. It complies with the Community Spin Guidelines

Step 1: Define the Spin as a Feature

Every Fedora release, the spin owner must 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, Add to Kickstart Pool

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. This step should occur 3 months out from the Feature Freeze Date.

  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 [SIGs/Spins/KickstartPool | spins kickstart pool]
  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:



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

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)

Step 3: Get Trademark Approval from the Fedora Board

Assuming that all technical due diligence has been done, the next step is to gain trademark approval from the board. The board may reject the spin at this point based on business or vision merits, but this should not be a technical discussion. Note, there is a slight overlap with Step 4 in that FEsCo will also review this on vision merits. This step should occur at least 2 months out from the Feature Freeze Date.

  1. The spin owner should subscribe to the advisory board mailing list.
  2. The spin owner should send an email to the board requesting Trademark Approval for the Spin.
    • This email should contain
      • A link to the feature page.
      • A link to the kickstart file in the GIT Repository
  3. The spin owner should look for the next scheduled meeting of the board and attend it.
  4. If approval is grantd, then the spin can be re-branded fedora and changes uploaded to the kickstart pool.

Note: This step can be omitted on subsequent releases unless the kickstart file is dramatically changed.

Step 4: Feature Approval from FESCO

At this point, the SPIN has had technical, Trademark, and high level vision review. FESCO will next review the spin for inclusion in the next Fedora Release. This review should focus not on technical merits, but rather on the vision of the SPIN (the value it brings to Fedora) and the capacity of Release Engineering to produce the spin. This step must occur before feature freeze, but since it is a

Note: This is basically the features policy. Defer to that page for the absolute steps on approval

  1. If you have not done so, join the Fedora devel list
  2. Email the FESCO Chair (found here) that you would like your feature discussed at the next meeting.
  3. Watch the devel list for the next meeting agenda, and attend the next meeting to discuss your feature.
  4. Iterate on the feature and kickstart file based on comments from the review.

Step 5: Release Engineering

Still working here, I will update as we go :)