Pseudo rolling release model

From Wiki [en] OpenMandriva
Jump to: navigation, search

What is rolling release model

In software development, a rolling release, rolling update, or continuous delivery is the concept of frequently delivering updates to applications

OpenMandriva repository structure

Well our repository structure is far from being user friendly. Just take a look:


Above structure is used for openmandriva2013.0,openmandriva2014.0 and 3.0.
Currently 1,3 TB is needed for our whole repository. With each release this value increases by around 0,3 TB.

Main cons of current repository structure

  • Our current repository structure does not fit „us” and it comes from ancient days
  • It is very greedy on disk space
  • Quite complicated for users
  • Each release we needs ~0,5 GB of free space
  • We „copy” same packages over the „releases” for example:

        cooker: foobar-1-1-omv2015.0.x86_64.rpm
        openmandriva2014.0: foobar-1-1-omv2014.0.x86_64.rpm

Proposition for an improvement

  • Cooker structure stays in a shape as it is now (unstable)
  • Sub dirs structure like main/{release,testing,..}, contrib, non-free stays in a shape as it is now
  • Introduce „stable” directory (3.0 renamed to stable)
  • Rename openmandriva2014.0 as „LTS”
  • Remove openmandriva2013.0 or rename it to legacy ?
  • ..main/testing/ may carry „stable cooker” future packages

Backporting flow

  • Packages first must be updated on cooker
  • Between cooker and stable there MUST be set some automatic tests that will do the check if RPM file is:
    • installable
    • does not produce conflicts
    • software is stable (does not crash)
    • and many more (can be defined later)

In simple words if one package is backported from one branch to another one it must be well tested before it got published.

How it should work?

  • Cooker follow current cooker rules
  • Stable repository is not frozen
    • New build rpm goes first to testing (../main/testing) then goes to release (../main/release)
  • LTS repository is frozen
    • New build rpm goes to testing (../main/testing) then goes to updates (../main/updates)
  • Legacy is frozen, updates are permitted but only critical ones
  • Keep current rule for software updates: first update cooker then do the testing and update other branches if necessary

Basically frozen repository means that RPM files are published first to /testing and after QA acceptance they got published to /updates
Not frozen repository allows RPM to be published first to /testing and after QA acceptance they got published to /release

How we are going to do releases ?

  • First do the release of 3.0, then rename 3.0/ to stable/ (symlink stable to 3.0 for compatibility)
  • Update software and develop new features in cooker tree
  • Push new software from cooker to stable/main/testing
  • Start QA procedure – extended with new features:
    • Run repository integrity tests (urpm-tools – urpm-repodiff, urpm-repoclosure for ../stable/main/release with rpms from ../stable/main/testing)
    • Integrate urpm-tools and many more various checks into ABF
    • Create QA module on ABF to allow to vote packages, check testing results etc.
  • Accept or reject update
  • Accepted software goes to ../stable/main/release
  • Build ISO based on ../stable/*/release
  • We can decide any time when we want to bump release version in distro-release package
  •  %distepoch is not so important anymore

What are the benefits?

  • Only 4 repositories (cooker, stable, LTS and legacy)
  • Decidated repository for LTS
  • Less requirements on disk space for mirrors and our infastructure
  • Better QA and integrity tests
  • User can easily use OMV Lx flavour which they want to use i.e.
    • Are you tired with Legacy ? Want to try something new and stable ?
    • just run urpmi.addmedia --distrib --mirrorlist
  • Stable repository is always stable, it will be updated with new software