From Mandriva Community Wiki

[edit] Bugfix and Functional Update Procedures

To minimize confusion and to give a point of reference for everyone as to the method of dealing with official bugfix and functional (i.e. non-critical) updates, the following procedures are to be implemented and observed by everyone (note that there are two procedures; one for consumer products, the other for Corporate products):

Note (for contrib and non-free packages): This procedures are only for official updates of packages in section main. If your package is in contrib or non-free, you're free to take advice from here, but not required to follow these procedures to the letter. Specifically, you must submit the package to its /updates section. Submitting first to /testing is recommended, but not required.

[edit] Mandriva (Consumer) Products

As of 2007.0, a new media has been implemented, the main/testing media. This media is where all non-critical bugfix and functional updates are to initially go. If the intention of the submitted packages is to go into the main/updates media, then the maintainer (submitter) of the packages must obtain adequate testing for those packages; preferrably via the community first, then via QA. Once QA has validated the packages, then packages can be forwarded to the security team to be rebuilt and placed into main/updates.

To ensure there is history and proof of validation, a bugzilla report must be opened for each package to be submitted. This bugzilla report must be used to have the comments and validation of QA and other testers. Then this bugzilla report will be used by secteam when preparing the update.

Maintainers/submitters must also provide an advisory text. Providing the changelog text is not sufficient. If there is no advisory text, secteam will not issue an advisory and QA will not test it. As well, if there is no bugzilla report, there will be no update issued, nor will QA test the update.

PLEASE NOTE: To avoid wasting everyone's time, it would be beneficial if, when opening the initial ticket, not only were instructions given to reproduce the bug/error (so as to make sure new packages are indeed fixed), but also to provide a small detailed "HOWTO" in order that QA and others can quickly setup or configure the appropriate software and test the reproducer without having to spend a lot of time doing initial research on how to use the software in the first place. Due to the large number of supported packages, assuming that everyone knows how to use (is using, has used, etc.) every package will, more often than not, result in the maintainer being asked to provide the details. So, to save time, the maintainer should include this information right when creating the report.

The following is the steps that must be followed to ensure a smooth update.

1. Maintainer patches and builds the package and tests it locally; the maintainer must provide a good (read: informative) changelog entry
2. Maintainer opens a bugzilla report for this update containing the advisory text to use and any additional information that will aid in testing (i.e. a test-case to trigger the fault, perhaps instructions on how to adequately test the software, etc.); a sample advisory text might be:
   • "The tiff loader from imlib2 crashes when processing images on the x86_64 platform. This was reported when using digikam on x86_64, which uses this loader."
     1. refer to Mandriva Advisories for many example advisories
     2. also please indicate clearly in the comments what version(s) this update is for as well as the explicit version/release to be tested to ensure the correct package is tested by QA and built by the secteam
   • The maintainer must assign the bug to qateam@ and place security@ in the CC field so that all parties are aware that a new update has entered the 'queue'
3. If there are public open bug reports, the Maintainer should insert the bugzilla report number (of the public bug, the Maintainer does not have to use the bug number of the new private/internal report requesting the update) into the changelog; for instance:
   • - fixed initscript (#12345)
4. Rebuild the package keeping %mkrel the same, or reset to 1 if it is a version update, and defining %subrel before %mkrel (start with %define subrel 1, increase for each update for the same %mkrel), and submit it to main/testing
5. Maintainer indicates in bugzilla that package foo is available in main/testing for updates; the bugzilla report should be public (not assigned to the security group for privacy) so that community members who are using main/testing can provide input on the packages as well, if so desired
6. QA tests the update and notes, in the bugzilla report, version(s) of package(s) tested, what test steps were taken, what the results of the testing were
   • If the package does not pass QA validation, the maintainer must correct the problem (which may be as simple as providing a better test-case or instructions on how to use the software, or may require fixing and recompiling the package)
7. If QA indicates the package is validated, this is noted in the report, including version(s) of package(s) tested, and the bug is reassigned to security@, with qateam@ (not qa@) in Cc
8. Secteam takes the src.rpm of the package and recompiles it on their clean chroot system
   • At this point the maintainer must remove the package from main/testing (QA? Secteam?)
9. Secteam performs cursory testing; depending on the package this could be as simple as an upgrade/install test or a more full battery of tests
10. Secteam uses the provided advisory text to create the advisory and releases the update
11. Secteam closes the bug report once the advisory is released

If any of these steps are not taken, the update cannot proceed. There are no exceptions.

Note: to submit packages for testing, two approaches are supported

1. the maintainer submits his/her patch into the SVN repository and triggers a rebuild, selecting the testing media as a destination. Use repsys for this (see Development/Packaging/BuildSystem/QuickRef#Upload for instructions)
2. the maintainer builds an src.rpm (as part of his own tests) and waits for positive test results before committing into SVN : use the youri tools in this case (like in mdv-youri-submit --define section=main/testing 2007.0 mypackage.src.rpm)

[edit] Mandriva (Corporate) Products

Mandriva Corporate products work in the same fashion, except there is no main/testing repository. There needs to be setup some mechanism for people to submit packages for Corp where the Corp4 QA can do the appropriate testing and then notify secteam of the updated and tested packages.

As with the consumer products, the Corp products must also have a bugzilla report from the moment the package is submitted. This bug can be assigned to QA and closed to the "security team group" to ensure that postings don't go to the cooker mailing list. All individuals besides QA, secteam (be sure to cc security@ in the report), and the reporter must be added to the CC in order to view the bug report.

As with the consumer products, if there is no advisory text and no bugzilla report, there will be no official update by the secteam.

Updates for Corporate products should follow the steps noted above in the same fashion as what is done for consumer products with the noted exceptions (i.e. lack of main/testing, etc.).