Difference between revisions of "Pseudo rolling release model"

From Wiki [en] OpenMandriva
Jump to: navigation, search
(Initial page)
 
m (How we are going to do releases ?)
 
(9 intermediate revisions by 2 users not shown)
Line 2: Line 2:
 
In software development, a rolling release, rolling update, or continuous delivery is the concept of frequently delivering updates to applications
 
In software development, a rolling release, rolling update, or continuous delivery is the concept of frequently delivering updates to applications
  
== OpenMandrvia repository structure ==
+
== OpenMandriva repository structure ==
  
Well our repostiroty structure is far from being user friendly. Just take a look:
+
Well our repository structure is far from being user friendly. Just take a look:
  
 
'''cooker'''/<br>
 
'''cooker'''/<br>
Line 28: Line 28:
  
 
Above structure is used for openmandriva2013.0,openmandriva2014.0 and 3.0.<br>
 
Above structure is used for openmandriva2013.0,openmandriva2014.0 and 3.0.<br>
Currently '''1,3''' TB is needed for our whole repository. With each release this value incerases by around '''0,3''' TB.
+
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 ===
 
=== Main cons of current repository structure ===
* Our current repository structure does not fit „us”
+
* Our current repository structure does not fit „us” and it comes from ancient days
 
* It is very greedy on disk space
 
* It is very greedy on disk space
 
* Quite complicated for users
 
* Quite complicated for users
Line 42: Line 42:
  
 
* Cooker structure stays in a shape as it is now (unstable)
 
* 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  
+
* Sub dirs structure like main/{release,testing,..}, contrib, non-free stays in a shape as it is now  
* Introduce „stable” directory (3.0 rename to stable)
+
* Introduce „stable” directory (3.0 renamed to stable)
 
* Rename openmandriva2014.0 as „LTS”
 
* Rename openmandriva2014.0 as „LTS”
* Remove opennmandriva2013.0 or rename it to legacy ?
+
* Remove openmandriva2013.0 or rename it to legacy ?
 
* ..main/testing/ may carry „stable cooker” future packages
 
* ..main/testing/ may carry „stable cooker” future packages
  
 
=== Backporting flow ===
 
=== Backporting flow ===
 
* Packages first must be updated on '''cooker'''
 
* 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:
+
* Between cooker and stable there '''MUST''' be set some automatic tests that will do the check if RPM file is:
 
** installable
 
** installable
 
** does not produce conflicts
 
** does not produce conflicts
Line 56: Line 56:
 
** and many more (can be defined later) <br>
 
** and many more (can be defined later) <br>
  
In a simple words if backage is backported from branch to another one i must be well tested before it got published.
+
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? ===
 
=== 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 acceptance they got published to '''/updates'''<br>
 +
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 ? ===
 
=== 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)
+
* 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
 
* Update software and develop new features in cooker tree
 
* Push new software from cooker to stable/main/testing
 
* Push new software from cooker to stable/main/testing
Line 78: Line 81:
 
* Accepted software goes to ../stable/main/release
 
* Accepted software goes to ../stable/main/release
 
* Build ISO based on ../stable/*/release
 
* Build ISO based on ../stable/*/release
* We can decide any time when we ant to bump release version in distro-release package
+
* We can decide any time when we want to bump release version in distro-release package
 
* %distepoch is not so important anymore
 
* %distepoch is not so important anymore
  
 
== What are the benefits? ==
 
== What are the benefits? ==
* Only 4 repositories
+
* Only 4 repositories (cooker, stable, LTS and legacy)
 
* Decidated repository for LTS
 
* Decidated repository for LTS
 
* Less requirements on disk space for mirrors and our infastructure
 
* Less requirements on disk space for mirrors and our infastructure
 
* Better QA and integrity tests
 
* Better QA and integrity tests
* User can easily use OMV Lx flavour which they want to use
+
* 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 <nowiki>http://downloads.openmandriva.org/mirrors/</nowiki>'''STABLE'''.x86_64.list
 
* Stable repository is always stable, it will be updated with new software
 
* Stable repository is always stable, it will be updated with new software
  
 
[[Category:Cooker]]
 
[[Category:Cooker]]

Latest revision as of 15:45, 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

OpenMandriva repository structure

Well our repository 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 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 http://downloads.openmandriva.org/mirrors/STABLE.x86_64.list
  • Stable repository is always stable, it will be updated with new software