Please remove this {{Draft}}template, when you're sure the page is complete and correct.
|
Contents
What is a backport?
Our policy is not to update to newer versions of packages in stable Mageia releases where possible but to apply patches for bugs and security vunerabilities. This helps to increase the stability of the distribution. For example you should not run into problems of incompatibility by updating a package. A new version may add or drop support for various things which could be disastrous if you were relying on that support for something important.
A backport is a new version of a package which is available in Cauldron, the development branch, and is being made available in our stable releases in special backport medias. These medias are not enabled by default and are not intended to be used as regular update medias.
For instance:
If there is a package called xmoto. There may be xmoto version 3.2 available in normal release or update medias. The functionality of xmoto 3.2 will not have changed between the time this particular Mageia was released and the time now.
Cauldron often has the latest versions, it is where the next Mageia release is being built, but it is not stable and can/will break. That is to be expected.
It may be that xmoto version 4 is available now in Cauldron, so the maintainer of xmoto has decided to also make it available in the stable Mageia releases as it adds some fancy function which isn't currently available. They can do that by providing a backport of xmoto 4 into the stable releases using the backport medias.
How to find backports waiting for validation
To prevent problems, backports are initially pushed to a testing repository waiting for the QA Team to validate them.
You can find backports waiting for validation on the same page as the bugfix and security update candidates, or directly in Mageia's Bugzilla. There is a saved search on Bugzilla called Backport waiting for QA test which you can find in your preferences. If you tick the box to the right of the saved search it will display a link in the footer of Bugzilla pages for you.
The actual packages are in the Backports Testing medias, as below:
$PROTOCOL://$MIRROR/path/to/Mageia/distrib/$ARCH/media/$MEDIA/backports_testing For example: http://ftp.belnet.be/mirror/mageia/distrib/1/x86_64/media/core/backports_testing
This example equates to "Core Backports Testing" in the media manager.
How to validate a backport
The process for validating a backport is similar to that for validating updates but testing is not as detailed. If you have packaged the backport then you may also certify that you have tested it on one architecture and that will count towards validation. The person requesting the package to be backported for them should be involved in the testing as much as possible.
Policy Checklist
Before starting to test the backport we should check that it is following the backports policy.
Things to be aware of:
- Backports will only be accepted for leaf packages or leaf "groups". This means packages which are not required by other existing packages. Imagine it as a tree, the leaves are the outermost bits which can be removed without affecting the twigs or branches.
- On Bugzilla, backports should be set as Backport in the Component field and low priority and should be treated as having the lowest priority by QA.
- A common sense advisory should be supplied similar to updates and should list RPM's and SRPM's so we can check they all install properly when it is selected.
- If a package is backported for Mageia 1, the same or a newer version must be in Mageia 2, either Release, Updates, or Backports
- If the backported package depends on another package to work, it should either work both with the version available in Release/Updates and in backports, or have strictly versioned requires - so selecting the main package should bring in everything that is needed in the right versions.
- Backports which are new packages must not obsolete other packages from Release or Updates
- The packager can certify that they have tested a backport on a specific Release and Architecture and it will count as one towards validation, provided they explain what they tested. This doesn't mean they can complete testing and validate their own backports without QA though.
- The person who initially requested the package to be backported for them should be involved in the testing as much as possible. We hope it will encourage new contributors!
Find out which architecture and Mageia release you use
In order to correctly categorize your QA work, it is necessary to know which architecture and Mageia release you use. To find out, enter
$ cat /etc/release
in a terminal or open the file /etc/release in any text editor. Then compare the output to the following table:
| Content of /etc/release | Architecture | Release (=Version) | Whiteboard Keyword |
|---|---|---|---|
| Mageia release 1 (Official) for i586 | i586 | 1 | MGA1-32-OK |
| Mageia release 1 (Official) for x86_64 | x86_64 | 1 | MGA1-64-OK |
| Mageia release 2 (Official) for i586 | i586 | 2 | MGA2-32-OK |
| Mageia release 2 (Official) for x86_64 | x86_64 | 2 | MGA2-64-OK |
Let others know
In order not to do the same job as other people from QA, duplicating the work, add a message to the update request on Bugzilla when starting work on it. Just something simple to let others know you are testing it.
An example of the type of message to leave:
Testing i586, MGA2.
Thanks.
Note: "i586" (Architecture) and "MGA2" (Release) must reflect what's present on your system.
We don't always do this step as there are usually more bugs than people so we don't tend to bump into one another but it can be used if the testing is likely to take some time or if it is something popular and easy to test.
On some complex packages it can be useful to have many people testing simultaneously. It can still be useful to let people know you are (also) testing the update.
Test
- Install the correct distribution with all the officially released updates. Check the “Product”, “Version” and “Platform” in the header of the bug report to find what it should be, e.g. Mageia 1 x86_64. Also note that, since the release of Mageia 2, some bugs may contain backportss for both releases so also check the advisory from the packager.
- Enable the relevant Backports Testing repository in your sources. See the Enabling the Testing media page for instructions how to do this.
- Install the backported package. Don't install everything from the Testing media, just the ones you are about to test. Ensure that it selects all the related packages, including any required libs. There should be a list of all the RPM's on the bug report.
- Disable the Testing repository again
- Make sure you now have the Backport installed. See here for instructions.
- Perform some quick checks to make sure the backport seems to work. Testing for backports need not be as thorough as testing of updates. It is enough to ensure that it installs cleanly with all required dependencies and seems to work OK.
- If it is a new package being introduced, check that it does not ask to remove any other package when installing it.
- If the backport is for Mageia 1 then ensure there is either a higher version or the same version in Mageia 2 Release, Updates or Backports, so there is a valid upgrade path.
- Do some quick tests to check that the update does not break anything else. As backports should only be leaf packages which don't affect anything else or leaf groups of packages then it should not affect other things.
- If your testing found a problem then feedback your findings by leaving a comment on the bug. The packager may request further information from you or need further testing to track down the problem so be prepared to follow it up. Include the release and architecture you were testing with.
For example..
Testing Mageia 2 i586.
I found a problem...etc.
Note: "Mageia 2" (Release) and "i586" (Architecture) must reflect what's present on your system. - If everything is OK then leave a comment to say that you have completed testing and add a keyword to the Whiteboard. The Whiteboard keywords help us keep track of when a bug is ready to be validated.
For example..
Comment: Testing complete Mageia 2 i586 for the SRPM chocolate-doom-1.7.0-1.mga2.src.rpm
Whiteboard: mga2-32-OK
Note: "Mageia 2" (Release), "i586" (Architecture) and "mga2-32-OK" (Whiteboard Keyword) must reflect what's present on your system. The keyword to use if you tested on an x86_64 Mageia 2 system would be "mga2-64-OK." - If the bug is ready for validating then validate it. A bug is only ready for validating when it has been successfully tested on both architectures on all releases it covers. As some bugs contain backports for more than one Mageia release, each must be completed for both i586 and x86_64 before it can be validated.
| Note: * Don't forget to enable the i586 medias on x86_64 systems
|
Validate
- Write a validation message to let people know the update has been properly tested on both architectures and, if necessary, all releases.
- Add a list of the tested/approved Source RPM's (SRPM's). For further information on finding the SRPM for a package, see the How to find a source RPM page.
- Add the advisory, rewrite it if necessary. The advisory is a description shown to users as the reason for the backport so it should be meaningful. Ask the packager to provide the advisory if it is missing or you don't know what to write. If it has already been posted and shows the current SRPM versions then either copy it into your comments or just link to the relevant comment. Bugzilla understands things like bug 6334 and comment 3 and will automatically turn them into links. Eg. See comment 3 for Advisory and SRPM.
- Add a message for the Sysadmin Team, asking for the packages to be pushed. Pushing means moving the packages from one media into another. For QA this means asking the sysadmins to push the SRPM from whichever Backports Testing media it is in, into the associated Backports media. It is actually all packages contained within the SRPM which are pushed. It will then be available to all Mageia users as a validated bakcport.
An example of the type of comment to leave:
------------------------------------------------------------------------------------------
Update validated.
Thanks.
Advisory:
--------------
This provides the new xmoto package for Mageia 1. It
adds a useful new xmoto widget for french fries which is not present in
the Release version.
It also disables support for Ketchup.
--------------
SRPM: xmoto.src.rpm
Could sysadmin please push from core/backports_testing to core/backports.
Thank you!
------------------------------------------------------------------------------------------
Then, at the top of the page: - Add sysadmin-bugs@ml.mageia.org into the 'CC' list so that the SysAdmin Team are aware it is ready to be pushed. Without this step they will not know that QA is complete and the package will not be moved to Updates so please don't forget!
- Add the validated_update keyword into the Keywords text box.
- Click on Save
What to do if...
...the packager is not following the backports policy
If the bug is missing information like the Advisory, SRPM's or list of RPM's then leave a message asking the packager to follow the backports policy.
For example:
Please follow the backports policy and provide an advisory with your request.
https://wiki.mageia.org/en/Backports_policy
Please reassign to QA when you have had a chance to look at this.
Thank you.
Then change the status to ASSIGNED and reassign the bug to the person who asked for QA to validate it.
...the update candidate does not fix the issue or creates another one
Simply reply in the update request by giving all the information about the bug or regression and which release and architecture you were testing on. Be prepared to follow up with further testing or information as requested.
If there is no response after a week has passed, reassign the bug back to the packager and change the status to ASSIGNED.
...you need help or guidance or are unsure of anything whatsoever
Please just ask! The only silly question is the one we never ask because we feel it is a silly question. You can either ask on IRC in #mageia-qa on irc.freenode.net or on the qa-discuss mailing list. If there is nobody available in #mageia-qa then you can always try in #mageia-dev too.
More information
Please refer to the QA Team portal for further information on the Mageia QA Team.
- Mageia's full updates policy.
- The QA Tips and Tricks page should provide you with some inspiration when performing testing.
- QA-Discuss mailing list: qa-discuss@ml.mageia.org
- QA-Bugs mailing list: qa-bugs@ml.mageia.org
- You can also use Mageia App Db to see pending update candidates and perform various useful comparisons.
- Sophie is a bot on IRC providing much useful information on Mageia packages.
Try typing :help in #mageia-qa or :more packagename
