| |
@@ -79,8 +79,8 @@
|
| |
=================================
|
| |
|
| |
* Send e-mail to
|
| |
- [https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/
|
| |
- epel-devel] with details of the proposed upgrade. Include items such
|
| |
+ `epel-devel <https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/>`_
|
| |
+ with details of the proposed upgrade. Include items such
|
| |
as the CVE of the security issue to be fixed, and/or an upstream bug
|
| |
tracker reference (if applicable). Also reference a bug in
|
| |
bugzilla.redhat.com against the package.
|
| |
@@ -97,19 +97,19 @@
|
| |
* Package MUST remain in testing for at least 2 weeks, regardless of
|
| |
received karma. In bodhi, 'Auto-request stable?' MUST NOT be
|
| |
checked.
|
| |
- * When pushing package to stable, the maintainer '''MUST''' send
|
| |
+ * When pushing package to stable, the maintainer **MUST** send
|
| |
another e-mail to epel-announce.
|
| |
|
| |
Procedure for other packages
|
| |
============================
|
| |
|
| |
- For other - non-security - updates, the maintainer '''MUST NOT''' push
|
| |
+ For other - non-security - updates, the maintainer **MUST NOT** push
|
| |
those types of changes to the stable package. Instead, a new package
|
| |
must be made, pass review, and be branched for EPEL only.
|
| |
|
| |
For example, an rdiff-backup upgrade for the reasons of an
|
| |
incompatible protocol change would be required to create a new
|
| |
- package, called ''rdiff-backup12'' and have that package pass review
|
| |
+ package, called ``rdiff-backup12`` and have that package pass review
|
| |
and imported into CVS.
|
| |
|
| |
Discussion points
|
| |
oturpe
commented 2 years ago
Looks like the content was imported from MediaWiki,
but some formatting was not converted to reStructured Text.