JeremyKatz/SpinChecklist

From FedoraProject

< JeremyKatz(Difference between revisions)
Jump to: navigation, search
(Imported from MoinMoin)
 
m (1 revision(s))
 

Latest revision as of 16:31, 24 May 2008

Stop (medium size).png DRAFT DRAFT DRAFT DRAFT DRAFT


In the creation and delivery of a new spin, Fedora Release Engineering will provide several services

Contents

[edit] Technical verification of the Contents

In the spin creation process, rel-eng will take care to help in the technical verification of the spin as being "reasonable" in conjunction with the Board's call on branding. This is intended to help ensure a certain quality level while allowing contributors more freedom in what they do in their configurations beyond just package list changes. Ultimately, we would like to be able to have a better set of guidelines to allow this work to be better distributed (like the PackagingGuidelines), but given the small body of experience thus far with creating spins, this is probably somewhat premature. A non-exhaustive list of things to check includes

  • Uses only official Fedora release and updates repositories
  • If this is a desktop oriented spin, it is based on the appropriate release -base-desktop.ks
  • No passwords should be hard-coded; instead, empty passwords should be used
  • Should be installable (unless it's a super minimal spin)
  • Ensure that %post section seems "reasonable"
  • ...

[edit] Testing of the Spin

To release a new live image as an Official Fedora Spin, some level of testing needs to be done to assure the quality of the spin. Prior to submission to the Board and Release Engineering, it is expected that the submitter has done at least the following minimal tests. More is always better.

  • Ensure the image builds
  • Ensure the built image boots
  • Test installation from the image
  • Other image-specific testing

Please outline the specific testing that you've done.

Once a spin is accepted to be built, it will first be done as a beta. This will be made available via bittorrent and announced to the Fedora testing community for testing for 2 weeks. If no blocker quality bugs are found, the image will be dubbed "final" and released. Note that respins of the image really need to have the 2 week window restarted due to updates being released in the interim changing the behavior of the image. Images which are spun three times and still have release critical bugs are dropped from being released and need to go through the entire approval process again.

Bugs for a spin should be filed against the component in bugzilla for the specific spin.

[edit] Spin Build Process

Stop (medium size).png This section is sparse. To be added to some by jwb

This is the actual process followed by release engineering when building the official ISOs for a given spin.

Log in to machine. Ensure version matches Fedora version a spin is being built for with appropriate version of livecd-tools. Get config. Run livecd-tools --config=/path/to/config --name=spin-label. Put on temporary HTTP site for download by rel-eng and SIG smoke tester. If it passes smoke test, move to beta. Once it's had 2 weeks of success, move to final.

[edit] Spin Updating

To avoid overloading of minimal release engineering resources as well as avoiding user confusion, spins should generally not be regularly updated over the life of a Fedora release. Exceptions to this can be brought to the Board on a case by case basis.

[edit] New Fedora Release

For each Fedora release, it is expected that the SIG will be active in ensuring their configuration still works and is accurate. If the SIG wishes to continue to have the spin released for the new Fedora release, this should be indicated by the beta freeze for that release and they should ensure their configs work by this time. Spins which are not in a buildable/working state by the beta freeze may be dropped from the release and have to go through the process of being approved again.

To help lower the confusion on release day, all spins may not be available at that time. Major spins will have priority and other spins may be released up to a month later (although a week is the goal).

[edit] Open Items

  • Where do bugs get filed?
  • Proposal: Each spin should have a component in bugzilla with the owner being the spin owner. This will hopefully avoid the bugs being filed against LiveCD or distribution
  • What should we use as the repo for spin configs?
  • Proposal: /cvs/spins on cvs.fedora. Then have directories per-release like package CVS
  • Tracking of SRPMS used for GPL requirements
  • Export approval. Does each new spin need to go through the export approval process