Packagers
General
Typically they have experience in packaging products or are the packagers for Mantis for one or more distributions. [giallu: I think it is very unlikely to be the packager on more of one distro, not a big deal though…]
The packaging team will have CVS commit access (same access level as Mantis developers and globalization team).
Ownership of Packaging Code
Communication with Linux Distributions
Maintain a list of Linux distributions that include Mantis.
Maintain a list of Linux distributions that we should approach to include Mantis. [giallu: do we really want to actively do this? ]
Keep close communication with Mantis packagers and Linux distributions.
Responsible for integrating patches supplied to them by Mantis packagers.
Work with Linux Distributions that provide a list of issues that need to be done for them to include Mantis.
Communicate to packagers and Linux distributions that only Mantis stable releases should be included in their distributions (whether stable or unstable). [giallu: this is not easy for all distros. For example, anyone feel free to correct me if I am wrong, debian stable is “stable” in the sense it will not change much overtime, and that only critical fixes are applied to packages, usually by backporting the patch]
Packagers can also use the “Contact Us” page to send emails to myself (vboctor) directly, then I can address or re-direct them to the appropriate news group or individuals.
Security Bugs and Advisories
[giallu: this whole section seems quite orthogonal to the packaging issue; of course distro packagers are interested in security issues/patches, but this list seems more suited for a security team, not a packaging one]
Manage the process of porting security bugs to the latest stable branch and make sure there are bugs to track such porting work (with summary starting with “Port:” prefix and adding a relationship of type “related”).
Make sure that security fixes have the required level of documentation to support the process of creating security advisories.
Maintain a list of sites on which we would like to submit our new advisories.
Decide and maintain the format of the security advisory.
Author and publish security advisories.
Make sure security bugs cross references security advisories (e.g. include CVE in summary).
Make sure security bugs are reported as private and are changed to public once a stable release is released.
Make sure the security category is used “wisely” in the bug tracker.
Duplicate security issues should be marked as such.
If there are N security issues that indirectly refer to the same issue, then they a parent issue should be created and that is the one that should be documented, fixed, included in the change log, and published as a security advisory.
Security fixes should include a description of the fix. It can be explanation of how to apply the fix, a patch, etc. This should allow packagers to apply the fix, users who are not ready to upgrade to also do the same.
Advisories that are hosted on the Mantis website will be hosted on the wiki and will be all linked from an index page. The index page should include a table with information like: date, CVE, bug #s, versions affected, and summary.