Difference between revisions of "Pseudo rolling release model"

From Wiki [en] OpenMandriva
Jump to: navigation, search
(What are the benefits?)
(How it should work?)
Line 59: Line 59:
  
 
=== How it should work? ===
 
=== How it should work? ===
* Cooker follow current cooker rules
+
* Cooker follow '''current''' cooker rules
* Stable repository is not frozen
+
* Stable repository is '''not''' frozen
 
** New build rpm goes first to testing (../main/testing) then goes to release (../main/release)
 
** New build rpm goes first to testing (../main/testing) then goes to release (../main/release)
* LTS repository is frozen
+
* LTS repository is '''frozen'''
 
** New build rpm goes to testing (../main/testing) then goes to updates (../main/updates)
 
** New build rpm goes to testing (../main/testing) then goes to updates (../main/updates)
* Legacy is frozen, updates are permitted but only critical ones
+
* 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
+
* Keep current rule for software updates first update cooker then do the testing and update other branches if necessary<br>
 +
<br>
 +
Basically frozen repository means that RPM files are published first to '''/testing''' and after QA acceptante they got published to '''/updates'''<br>
 +
Not frozen repostiory allows RPM to be published rist to ' and after QA acceptante they got published to '''/release'''
  
 
=== How we are going to do releases ? ===
 
=== How we are going to do releases ? ===

Revision as of 14:59, 30 June 2016

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

OpenMandrvia repository structure

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

cooker/
     SRPMS/
     aarch64/
     armv7hl/
     i586/
     x86_64/
          contrib/
          debug_contrib/
          debug_main/
          debug_non-free/
          debug_restricted/
          main/
               media_info/
               release/
               testing/
               updates/
          media/
          non-free/
          restricted/


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 incerases by around 0,3 TB.

Main cons of current repository structure

  • Our current repository structure does not fit „us”
  • 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 like main{release,testing,..}, contrib, non-free stays in a shape as it is now
  • Introduce „stable” directory (3.0 rename to stable)
  • Rename openmandriva2014.0 as „LTS”
  • Remove opennmandriva2013.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 are 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 a simple words if backage is backported from branch to another one i 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 acceptante they got published to /updates
Not frozen repostiory allows RPM to be published rist to ' and after QA acceptante 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 ant 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 http://downloads.openmandriva.org/mirrors/STABLE.x86_64.list
  • Stable repository is always stable, it will be updated with new software