Wiki » Backports policy

Overview

People are expecting to get newest versions of their favourite software in stable versions of Mageia. Given the current level of resources, this document establishes our policy regarding Mageia backports. Should those resources change substantially, then a review of this policy may be required.

Purpose

This policy aims to provide the minimal quality users can expect from Mageia packages. Priority will focus on whatever happens on the security updates for stable version.

Packages scope

• leaf packages
• leaf group of packages (a group of packages no external package depends on). It means that you must carefully check dependencies before backporting, and are allowed to backport a lot of packages provided you're ready to support them all and have them all properly tested. See the cherry-picking constraint below, though.
• packages not present in the distribution (provided it doesn't obsolete or provide stuff that would impact the distribution, like backporting a new jvm with an obsolete on the current one)

A list of never backportable packages will be created to avoid big breakages (rpm, glibc, python, perl, xorg, ...)

Version and dependencies Policy

We need to ensure that upgrades never fail: cauldron must always have a higher version/release than in stable releases.

Backports can be cherry-picked (ie, enable backports, install, disable backports). It means too that there must be strict requires between backported packages, in order to make sure they can be cherry-picked.

Roles and process

Prerequires

• Package maintainers are under no obligation to provide backports for the packages they maintain (whereas a maintainer should provide updates to the stable releases for packages he/she maintains).
• Another packager can step in and provide backports provided he contacts maintainer about this. He must then keep the maintainer informed when working on it.
• The maintainer can refuse that some packages be backported. If hard conflicts arise (eg. the maintainer vs all other packagers), we can refer to the council.
• Packager (maintainer or not) who will submit backport will also have to provide security and bug updates if necessary.

Steps

User

• Open a bug report in bugzilla asking for a backport

Triage

• identify backport requests
• add "Backport Request: " in the bug report summary
• add the "backport" keyword
• assign to maintainer

The maintainer can refuse to do the backport, but must give a reason:

• doesn't want to maintain it => assign the bug report back to bugsquad@mageia.org so that another packager can step in
• has a good reason for not providing this backport (policy, possible breakage...) => close as wontfix

Packager

• first of all check that your backport is not against the policy

Import a new backoport

• copy package from cauldron branch to backports branch

svn cp svn+ssh://svn.mageia.org/svn/packages/cauldron/hplip  svn+ssh://svn.mageia.org/svn/packages/backports/5/ -m "SILENT: copy for backport"

Update existing backport

• get the current sources mgarepo co package_name -k mgaversion by example

mgarepo co foo -k 5

Send the backport to BS

• submit to {core,nonfree,tainted}/backports_testing from the backports branch

mgarepo submit  --define section=core/backports_testing -t 5

• find a tester: original bug reporter when there is one, yourself if there's none, or ask in forums/irc/MLs...
• once tested by at least one person (it must be said explicitly in the bug report, with testing procedure given so that QA can know how it was tested and how to test it), hand it to QA:
  • create bug report if not done already
  • set the bug component to "Backports"
  • set severity to enhancement for new packages or feature-only updates. Set it to normal, major or critical for bugfixes to existing backports, depending on the severity of the bug(s)
  • make sure the bug report summary starts with "Backport Request: " or "Backport Candidate: "
  • assign to qa-bugs@ml.mageia.org
  • list the source RPMs and RPMs (don't forget to list packages from tainted media if the package is both in core and tainted)
• be ready to fix bugs and answer QA team questions

QA

• QA team will test backports, but with lower priority than that of bugfix and security updates
• test backports in a similar way that we test updates.
  • Detailed validation process: QA process for validating backports
• move the packages from backports_testing to backports

Packager again

• be ready to fix bugs: once you pushed a backport, you have to maintain it until the distribution's end of life :)

Authors

• Stormi
• Misc