Difference between revisions of "Policies/Repository Policies"

From Wiki [en] OpenMandriva
Jump to: navigation, search
m (+ Category)
(clarify exceptions)
 
Line 14: Line 14:
 
= Rolling =
 
= Rolling =
 
Rolling needs to be usable for normal people at all times. Stuff that breaks things badly can not go into Rolling. To make sure Rolling is always usable:
 
Rolling needs to be usable for normal people at all times. Stuff that breaks things badly can not go into Rolling. To make sure Rolling is always usable:
* Anything sent to Rolling must be built in cooker first. (Exception: Something where cooker has a newer version of the same thing already, e.g. it can make sense to push LLVM 8.0.1 to Rolling even when Cooker has already moved on to the 9.0 branch)
+
* Anything sent to Rolling must be built in cooker first. (Exception: Something where cooker has a newer version of the same thing already, e.g. it can make sense to push LLVM 8.0.1 to Rolling if Rolling is at 8.0 even when Cooker has already moved on to the 9.0 branch)
 
* Developers send packages to rolling/testing - not rolling/release - when they think stuff is ready for general consumption. Moving stuff from rolling/testing to rolling/release is done by QA, to make sure packages have been tested in the Rolling environment.
 
* Developers send packages to rolling/testing - not rolling/release - when they think stuff is ready for general consumption. Moving stuff from rolling/testing to rolling/release is done by QA, to make sure packages have been tested in the Rolling environment.
 
* Rolling should usually not use beta releases/snapshots of upstream software. There are exceptions to this rule (e.g. where upstream is caught in a "release never" cycle, a beta/snapshot is the only one that works in our environment [e.g. "stable" release still uses Qt 4 or Python 2], or there's other good reasons).
 
* Rolling should usually not use beta releases/snapshots of upstream software. There are exceptions to this rule (e.g. where upstream is caught in a "release never" cycle, a beta/snapshot is the only one that works in our environment [e.g. "stable" release still uses Qt 4 or Python 2], or there's other good reasons).
Line 22: Line 22:
 
This is the stable release tree. It gets only important updates, such as security fixes or fixes for system crashes. People who want the latest version of something should use Rolling instead.
 
This is the stable release tree. It gets only important updates, such as security fixes or fixes for system crashes. People who want the latest version of something should use Rolling instead.
 
This means people who use Rock want something that never breaks, special attention must be paid when making any change whatsoever in Rock.
 
This means people who use Rock want something that never breaks, special attention must be paid when making any change whatsoever in Rock.
* Anything sent to Rolling must be built in Rolling first. (Exception: Something where cooker has a newer version of the same thing already, e.g. it can make sense to push LLVM 8.0.1 to Rock even when Rolling has already moved on to the 9.0 branch)
+
* Anything sent to Rolling must be built in Rolling first. (Exception: Something where cooker has a newer version of the same thing already, e.g. it can make sense to push LLVM 8.0.1 to Rock if Rock is at 8.0 even when Rolling has already moved on to the 9.0 branch)
 
* Developers send packages to rock/testing - not rock/release - when they think stuff is ready for general consumption. Moving stuff from rock/testing to rock/release is done by QA, to make sure packages have been tested in the Rolling environment.
 
* Developers send packages to rock/testing - not rock/release - when they think stuff is ready for general consumption. Moving stuff from rock/testing to rock/release is done by QA, to make sure packages have been tested in the Rolling environment.
 
* Rock should usually not use beta releases/snapshots of upstream software (and be even more careful about this than Rolling). There are exceptions to this rule (e.g. where upstream is caught in a "release never" cycle, a beta/snapshot is the only one that works in our environment [e.g. "stable" release still uses Qt 4 or Python 2], or there's other good reasons).
 
* Rock should usually not use beta releases/snapshots of upstream software (and be even more careful about this than Rolling). There are exceptions to this rule (e.g. where upstream is caught in a "release never" cycle, a beta/snapshot is the only one that works in our environment [e.g. "stable" release still uses Qt 4 or Python 2], or there's other good reasons).

Latest revision as of 21:14, 4 June 2019

Cooker

Cooker is an experimental branch that can break at times. Most things are ok to do here, including updating to a beta version or even a git/svn/cvs/hg/whatever snapshot of an upstream package. To make sure you don't "surprise" other developers by breaking everything for them, major changes need to be coordinated by either:

  • bringing them up in a TC meeting
  • sending a pull request on the repository and waiting for others to accept it
  • sending an email to the cooker ML and waiting for others' positive reply

Changes that need coordination include, but are not limited to

  • switching out a major system component for something else (e.g. Xorg -> wayland, Qt 5 -> Qt 6, wpa_supplicant -> iwd, systemd -> any other init system, ...) -- any such change should be tested in a personal repository first.
  • update that will require a load of rebuilds (e.g. updating libpng to a version with a new soname)
  • dropping a package used by many things (e.g. dropping qt5 when qt6 is out and has been stabilized)
  • changes that are likely to break other people's hardware

Cooker is usually open for all types of development, but can be frozen at some times to consolidate efforts on one branch.

Rolling

Rolling needs to be usable for normal people at all times. Stuff that breaks things badly can not go into Rolling. To make sure Rolling is always usable:

  • Anything sent to Rolling must be built in cooker first. (Exception: Something where cooker has a newer version of the same thing already, e.g. it can make sense to push LLVM 8.0.1 to Rolling if Rolling is at 8.0 even when Cooker has already moved on to the 9.0 branch)
  • Developers send packages to rolling/testing - not rolling/release - when they think stuff is ready for general consumption. Moving stuff from rolling/testing to rolling/release is done by QA, to make sure packages have been tested in the Rolling environment.
  • Rolling should usually not use beta releases/snapshots of upstream software. There are exceptions to this rule (e.g. where upstream is caught in a "release never" cycle, a beta/snapshot is the only one that works in our environment [e.g. "stable" release still uses Qt 4 or Python 2], or there's other good reasons).

Rolling goes into freezes shortly before new releases are made, so releases can be made as essentially a snapshot of rolling/release.

Rock

This is the stable release tree. It gets only important updates, such as security fixes or fixes for system crashes. People who want the latest version of something should use Rolling instead. This means people who use Rock want something that never breaks, special attention must be paid when making any change whatsoever in Rock.

  • Anything sent to Rolling must be built in Rolling first. (Exception: Something where cooker has a newer version of the same thing already, e.g. it can make sense to push LLVM 8.0.1 to Rock if Rock is at 8.0 even when Rolling has already moved on to the 9.0 branch)
  • Developers send packages to rock/testing - not rock/release - when they think stuff is ready for general consumption. Moving stuff from rock/testing to rock/release is done by QA, to make sure packages have been tested in the Rolling environment.
  • Rock should usually not use beta releases/snapshots of upstream software (and be even more careful about this than Rolling). There are exceptions to this rule (e.g. where upstream is caught in a "release never" cycle, a beta/snapshot is the only one that works in our environment [e.g. "stable" release still uses Qt 4 or Python 2], or there's other good reasons).
  • Updates should usually not change the user interface. People using Rock want something they're familiar with and don't want surprises.
  • "If in doubt, don't do it." -- people who want the update for something that isn't important should use Rolling