Mission Statement

From RockWiki

Jump to: navigation, search

On Chemnitzer Linux Tage 2006 we agreed on a Mission Statement - after 10 years of ROCK, we felt it's about time ;).

Contents

Official Wording

  • ROCK Linux is a Distribution Build Kit.
  • We as the ROCK Linux core developers test and try to ensure functionality of
  • We also update the basic packages to follow their on-going development.
  • We gladly host other packages and targets as well, but don't guarantee anything.
    • No duplicate packages are allowed, though.
  • We do stable Source Releases regularly (for Distribution Builders).
  • We do Crystal ROCK and other Binary Releases as we see fit.
  • We issue Security Advisories and maintain Errata Documents.
  • We try to keep trunk as stable as Source Releases, but can't guarantee it.

As we try to keep trunk stable, all changes to core parts that may have side-effects undergo the following tests. Changes that introduce obvious errors have to be fixed before they can be applied.

  • The changes are used in one bootdisk and one Crystal build (with default settings for expert options).
  • The resulting ISO image must be bootable and suited for local installation of the Crystal build.
  • Configuration tasks provided by the setup tool (stone) should work as expected.
  • The installed or updated system is booted, and tested run-time. Special attention is paid to basic system software, such as:
    • early userspace (initial ramdisk)
    • login, user and group management
    • automated hardware detection and hotplugging
    • the X11 server, runlevel 5 login, overall GUI usability

Feel free to suggest a textual interpretation of these points if you like!

Textual Interpretations

stf, blindcoder

  • ROCK Linux is a Distribution Build Kit. It is not a distribution, but a framework and set of tools for creating highly customized distributions.
  • We as the ROCK Linux core developers test and try to ensure functionality of
  • We also update the Basic Packages to follow their on-going development.
  • We host other packages and targets as well (Third Party Software), but don't guarantee that they will work.
    • No duplicate packages are allowed, though. Changes to packages should always be coordinated by the respective maintainers.
    • The respective maintainers are primarily responsible for updates and bug or security fixes. If they do not vote for or against changes within a week, those changes can be applied by core developers.
  • We do stable Source Releases (for Distribution Builders).
  • We do Crystal ROCK and other Binary Releases as we see fit. This may be
    • for events
    • because of big changes
    • or because it's someones birthday :-)
  • We issue Security Advisories, and maintain Errata Documents for our releases.
  • We try to keep trunk as stable as the Source Releases, but can't guarantee it.

As we try to keep trunk stable, all changes to core parts that may have side-effects undergo the following tests. Changes that introduce obvious errors have to be fixed before they can be applied.

  • The changes are used in one bootdisk and one Crystal build (with default settings for expert options).
  • The resulting ISO image must be bootable and suited for local installation of the Crystal build.
  • Configuration tasks provided by the setup tool (stone) should work as expected.
  • The installed or updated system is booted, and tested run-time. Special attention is paid to basic system software, such as:
    • early userspace (initial ramdisk)
    • login, user and group management
    • automated hardware detection and hotplugging
    • the X11 server, runlevel 5 login, overall GUI usability

Feature Freeze

When preparing source releases, the core developers set a Feature Freeze on the core parts of trunk, which means that

  • only bug and security fixes are applied until trunk is found stable and well-tested enough for a new release.
  • Package updates can be applied if they contain bug fixes only, or security fixes - adding features should be avoided, to prevent introducing new bugs in depending packages (for example: API changes).

Source releases are named by their respective revision numbers. Official binary releases are based on source releases and created by core developers.

Retrieved from "https://www.rocklinux.net/wiki/Mission_Statement"