Backports policy

Overview

People are expecting to get newest versions of their favorite softwares in stable versions of Mageia. Given the current level of ressources, this is the Mageia policy for backports. It should be reviewed in 6 months after reviewing these resources.

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
• 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 a 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 cherrypicked.

Roles and process

Prerequires

• There is no obligation to provide backports for the maintainer of a package (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 keep the maintainer informed then 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

• create bug report if not done already
• copy package from cauldron branch to backports branch
• submit to {core,nonfree,tainted}/backports_testing from the backports branch
• 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), hand it to QA :
  • make sure the bug report summary starts with "Backport Request: " or "Backport Candidate: "
  • add the "backport" keyword if missing
  • assign to qa-bugs@ml.mageia.org
  • list the source RPMs if there are several
• be ready to fix bugs and answer QA team questions

QA

• test backports the same way that we test updates. But don't forget that updates have a higher priority than that of 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