From Fedora Project Wiki

Revision as of 19:58, 21 October 2010 by Mdomsch (talk | contribs) (initial text)

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

These are the requirements the Fedora Project places on any media created by the Project, intended to be handed out to end users by Ambassadors at events.

Requirements

Fit-and-Finish

Media artwork

  • Media must have Fedora-themed artwork
  • Artwork must clearly describe what is on the media. Example: "Fedora Desktop, i686 architecture"

Media sleeve artwork

  • Sleve must have Fedora-themed artwork
  • Artwork must clearly describe what is on the media. Example: "Fedora Desktop, i686 architecture"
  • Artwork must clearly describe minimum system requirements

Boot Screens

  • Boot screens must have Fedora-themed artwork, or no artwork at all
  • Boot screens default selection must be the item we expect most users to choose, especially if they are new to Fedora
  • Boot screens may layer in additional selections

Produced by Release Engineering

  • ISO files are produced from packages in the Fedora repositories, by the Release Engineering team, using tools in Fedora.

Quality Assurance

  • Must have an approved test plan on file with the Fedora Quality Assurance team
    • Test plan should be written involving members of the QA team
  • Test plan must be executed by someone, with review by a member of the QA team. NB: this requires at least 2 people to participate in the testing.

Corresponding Source Code Compliance

Non-Requirements

Hosting by Fedora Infrastructure

It has traditionally been our practice to host our media ISO images on Fedora Infrastructure servers, which include both http://alt.fedoraproject.org for "alternative" content such as Spins, and on the Fedora Mirror System. It is not a strict requirement that we do so, but it makes it easier for people to obtain an ISO that matches physical media.

Production of matching ISOs containing only SRPMs

By providing the list of SRPMs in the correspondingsource git tree, it is possible to create on an as-needed basis an ISO containing those SRPMs. This removes the need to produce and store an ISO image of these ahead of time.