Policies/Maintainers policy

From Mandriva Community Wiki

Please note!
This is a draft version of the policy. Feel free to discuss the proposals on the Discussion page.

Mandriva Maintainers Policy

Maintainers policy and etiquette:

• Each maintainer is responsible for supporting his packages during the official lifetime of Mandriva distribution versions, tracking updates to his software from upstream, and fixing security issues working together with the secteam. If necessary, secteam can proceed with security updates for packages if:
  • A maintainer has not been reached in a timely matter
  • A maintainer did not released an update for a security issue in a timely matter
  • A security issue is embargoed due to an agreement between distribution vendors. In this case, the security team will contact the maintainer to decide the best moment for releasing the security update.
• Maintainers must use their @mandriva.org or @mandriva.com email address to commit and update packages and commenting/following up bugs.
  • If a maintainer uses his personal email address, his comments and modifications will be seen as his personal view on the matter, and not official reply as a maintainer.
• Each maintainer is supposed to answer to bugzilla requests upon his packages in a timely matter. In case of non-responsive maintainers, the corresponding policy applies as explained below.

Maintainers responsibilities for Mandriva repositories

• Packages in Main repository are essential for a working Mandriva installation. Therefore, more strict rules apply to such packages:
  • The maintainer of a package in Main repository is allowed to commit into his packages and release them. The usual Version and Release Freeze policies apply when necessary.
  • Commits from non-maintainers are automatically queued into a review system, and are approved after a due review by the maintainer. In case a maintainer decides to reject a commit, he should provide an explanation why a commit is rejected.
  • Only the official maintainer is allowed to release package updates.
  • Co-maintainership for packages is possible. In this case, any each of co-maintainers has the same authority to review the commits and commit/release packages.
• Packages in Contrib repository are provided and supported by the community. Therefore, the authority upon the packages is given to the maintainers, and each maintainer can decide whether he prefers:
  • Anyone to commit and release the packages he maintains
  • or be notified about all commits and approve/reject/comment them
• Anyone can contribute new packages into the Contrib repository. New packages are subjected to an initial review by a Mandriva Maintainer when added. After approval, the usual policies apply.

Inactive and Non-responsive Maintainers policy

How to proceed with non-responsive and inactive maintainers.

• File a bug against the package in bugzilla asking for the maintainer to respond (after checking if the maintainer is on Vacation ).
• After every 7 days, the reporter adds a comment to the bug report for each unsuccessful attempt to contact.
• After 2 attempts of no contact, the reporter asks if anyone knows how to contact the maintainer.
• After another 7 days, the reporter posts a formal request to the Mandriva Maintainers list with the bug link.
• If at least one Mandriva maintainers approves the takeover and no one objects within 3 days, the requester may take over the package. If the requester is a not an existing Mandriva contributor, they may still take over the package and become a junior maintainer for it. In addition to this, the new owner must also reassign any open bugs on that package to themselves.

Non-maintained packages

• If a package has no maintainer, any Mandriva maintainer is allowed to commit and release it when he judges necessary, until a maintainer is found.
• After a package gains a maintainer, the usual Maintainers policy applies.

Exceptions and issues solving

Super-maintainers

• In order to cope with possible and unexpected issues, some maintainers can be designated as "super maintainers". These maintainers have the power to perform commits to packages in order to solve emergency issues (critical build failures which result in non-operating BS; packages whose maintainers were MIA; and other critical issues which require immediate intervention).
  • In the case of critical build failures and serious issues in critical packages, a bug must be opened by the super maintainer, describing the situation and the actions taken. This bug must be assigned to the maintainer of the package in question, so he could comment on it afterwards.
  • In case of non-responsive maintainers, the required actions can be carried out after the policy described in previous section
  • In order to provide a better issues coverage, we propose the creation of 4 "super maintainers", having 2 maintainers nominated from Mandriva, and 2 maintainers suggested by the Community.
  • In case of split decision (for example, 2 super-maintainers have one opinion; and other 2 have opposite one), the final decision will be taken by the Cooker manager. (this is a proposal, please feel free to propose other solutions)

Mass rebuilds

• Several situations, such as mass-rebuild of packages, require commits to packages which belong to different maintainers. In this case, such commits can be requested by the Maintainer of the package in questions via bugzilla, and carried out by one of super-maintainers.