Post-Release Support Policy

From Mandriva Community Wiki

(Redirected from Policies/Support)
Jump to: navigation, search
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).
Please note!
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.


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 are the steps that must be followed to ensure a smooth update.

Maintainer steps

  1. The maintainer patches and builds the package(s), and tests locally, making sure he is basing the update candidate upon the latest SRPM in updates (and verify it against what is in subversion); special care must be taken to keep security patches on version upgrades, or make sure they're merged; he must provide a good (read: informative) changelog entry
  2. The 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.); if more than a single source package is to be updated, all must be referred to in the bug description; 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@ (not qa@) and place security@ in the CC field so that all parties are aware that a new update has entered the 'queue', and Bugzilla searches show it
  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. Submit the package(s) to main/testing, keeping %mkrel the same, or reset to 0 if it is a version update, and defining %subrel before %mkrel (start with %define subrel 1)
  5. The maintainer indicates in Bugzilla that the package(s) is(are) available in main/testing for updates; the Bugzilla report should be public (not assigned to the private Security group) so that community members who are using main/testing can provide input on the packages as well, if so desired

Note about %subrel and %mkrel usage

Regular updates for stable releases should not change %mkrel of the package, but instead increase %subrel (starting at 1). Version upgrades for stable relases, on the other hand, should set %mkrel to 0, as well as set %subrel to 1. This is so that packages are always upgraded for newer distro versions (assuming a package receiving a fix in and old distro release, will also be fixed in Cooker, thus have %mkrel increased, and being at least 1).

Note on repsys usage

To checkout and submit packages for the testing section, use repsys or mdvsys. Examples:

  repsys co svn+ssh://
  repsys submit --define section=main/testing -t 2009.0 svn+ssh://$the_package@$the_revision

For more details on repsys or mdvsys usage see Development/Packaging/BuildSystem/QuickRef.

Note about DKMSs

For DKMS bugfix updates, the maintainer must request QA team to install the dkms-foo package, not the binary DKMS, and have them check (as much as possible, given testing conditions/available hardware/etc.) it builds/installs/works properly (preferrably for all available, or relevant, kernels supported). Once qateam approves the package, it'll go its way into main/updates, as usual, and binary DKMS will be provided in the next kernel update, only if the specific binary DKMS was also provided at release time (that is, if a binary DKMS was not provided at release, it also won't be provided with updates, as we only worry about keeping kernel upgrades working).

Note about security fixes

Security fixes for main are fully handled by Secteam, usually following Mitre's CVE dictionary. QA team is not expected to check for security subtleties. Also, some security issues may have embargo dates, so they may be on the works even if you won't be told about it. Because of that, maintainers should not submit security fixes (for main) via this procedure. Instead, a bug report should be opened and assigned to security@ (and also check the Security group checkbox), attaching any patches and testcases to it. If you still want to submit a security fix via this procedure, or have doubts, contact Secteam first, to prevent wasting your time.

QA team steps (qateam@...)

  1. QA team 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 update 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 rebuilding the package(s))
    • If QA team indicates the update is validated, this is noted in the Bugzilla report, including version(s) of package(s) tested, and the bug is reassigned to security@, with qateam@ (not qa@) now in Cc

Secteam steps

  1. Secteam takes the src.rpm of the package(s) and rebuilds it on their clean chroot system, simply increasing %subrel and adding a short changelog entry for the rebuild
  2. Secteam uses the provided advisory text to create the advisory and releases the update
  3. Secteam closes the bug report once the advisory is released
Caution !
If any of the above delineated steps are not taken, the update will not proceed. There are no exceptions.

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.).

Personal tools