From Mageia wiki
Jump to: navigation, search
Drakconf multiflag.png
Other languages

Deutsch ; English ; Français ;


This is a first pass at formalizing an update policy for the released distribution. Things are not set in stone, but we need a policy to move ahead with releasing updates for Mga-current, and we can refine the process as we find issues/shortcomings. In my mind, there are at least two characterizations of the distribution we want to avoid at all costs:

  • Mageia is slow to fix bugs and release updates
  • Mageia routinely releases untested updates that break things

While we all know "stuff happens" and the occasional bad update gets out, we all need to do due diligence to release timely, fully QA'd updates.


An update shall be issued to either correct a defect in an application or packaging (bug) or to address a security vulnerability. Ref: Bug Policy

Version Policy

For the most part, an update should consist of a patched build of the same version of the package released with the distribution, with a few exceptions:

  • Bug fix only release. There is no point in shipping all the fixes as patches if the new version does not contain any new feature.
  • Software versions that are no longer supported upstream with updates (firefox and thunderbird seem to fall into this category these days)
  • Software that is version-bound to an online service (games, virus scanners?) and will only work with the latest version.
  • We will make exceptions for packages that did not make it into Mga-current and are additions to the distribution, provided they do not impact any other packages and can pass full QA.

Updates are not the appropriate place for packages created to satisfy certain user's urges for "the latest". These types of builds belong in backports.


Several groups are involved in the request for, creation, testing, and release of updates:

Community (anyone)

(Note: The more complete the work here, the faster we can release timely updates):

  • Identification of issue.
  • Report bug
  • locate patches and attach to bug
  • identify relevant entries in other bug databases, security issue databases
  • locate POC (Proof of Concept) that illustrates the vulnerability and attach to bug
  • test and provide feedback as updated packages appear in testing media

Bug Triage Team

  • Review bugs for completeness
  • Request additional information if needed
  • Assign bug to maintainer

Maintainer (or any interested packager)

  • Build updated package with fixes (if the bug is not already assigned to you, assign it to yourself, so others know you're working on it)
    • If the version didn't change, leave mkrel as is and '%define subrel 1'
    • If it's an update to a new version: use '%mkrel 1' without subrel

IMPORTANT: subrel must be defined above/before mkrel to work

  • Do at least some initial QA to check that the application/fix works, for a security update a link to the related upstream security announcement or CVE should be provided, also a proof-of-concept (POC also known as exploit) should be provided if available to check if the update fixes the security issue reproducibly
  • Submit the package to updates testing. Check the mgarepo page for the procedure to submit the package.
  • Write the update announcement/advisory in the bug report used to validate that update (Example update advisory announcement)
  • Reassign the bug to (add a comment in the bug with the package version/release at re-assign, should be already contained in said advisory/announcement). If the update fixes more than one bug, re-assign just one of them.
  • Lists ALL SRPMS needed for the update (see why in bug 3949) and also all RPMs as QA need to know what to test.

QA Team (How to check and validate an update)

  • Test that package(s) will install on all supported architectures
  • Ensure that package(s) can update from the previous version(s)
  • Ensure that the specific issue has been addressed and the application still performs as expected
  • For a security vulnerability, if a POC is available and within QA's skills to test, test that the new version is immune to the vulnerability (QA can defer to Maintainer or Security Team for guidance or assistance)
  • If a package fails QA, loop back to the bug with comments and repeat the fix/package/test cycle until we reach satisfactory results.

Security Team

  • Monitor security mailing lists and other sources of security information for issues affecting supported releases, as well as Cauldron
  • Open bugs or notify maintainer of issues (as always, a bugzilla entry is something concrete people can work off of and ensures things don't "fall through the cracks")
  • Design POC (Proof Of Concept) if necessary/possible to test whether updated build is immune to the issue
  • Work with Maintainer and QA for any security specific issues with patches, application behavior.
  • Participate in closed vendor-cooperation security lists and ensure we comply with embargo agreements. Maintain a presence such that we become a trusted member of the security community.

Sysadmin Team

  • Push the package from updates_testing to updates, using a script
  • Send mail on the list ( using a script )
  • FIXME publish update announcements to web pages
  • FIXME delegate to someone else this job ( proper setup of sudo, etc )