From 62b2b64ecc72be9190181f03076cfd6207a4d376 Mon Sep 17 00:00:00 2001 From: Ondrej Nosek Date: Jun 29 2022 04:09:58 +0000 Subject: CONTRIBUTING.md fix links Links have a different format in markdown syntax in Pagure. JIRA: RHELCMP-9383 Signed-off-by: Ondrej Nosek --- diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index ee37436..b3c1d31 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,80 +1,83 @@ ## Index -* [Places and links](#places) -* [Testing](#testing) -* [Release process](#release-process) -* [Documentation](#documentation) -* [Code-review process](#code-review) +* [Places and links][places] +* [Testing][testing] +* [Release process][release-process] +* [Documentation][documentation] +* [Code-review process][code-review] # Contributing **We love seeing Pull Requests from anyone.** -For bigger or controversial changes, consider first discussing it via [issue](#issue) or any other method with the maintainers of this repository. Otherwise, there's a risk they might disagree with it and you could spend time on it in vain. Or you can just open a Pull Request and keep the discussion there. +For bigger or controversial changes, consider first discussing it via [issue][issues] or any other method with the maintainers of this repository. Otherwise, there's a risk they might disagree with it and you could spend time on it in vain. Or you can just open a Pull Request and keep the discussion there. All code should work well with Python 3 and also be compatible with Python 2.7. -Code is [reviewed](#code-review) by package maintainers. +Code is [reviewed][code-review] by package maintainers. -### Sign Off +### Sign Off -All commits must be signed-off on. Please use `git commit -s` to do that. This serves as a confirmation that you have the right to submit your changes. See [Developer Certificate of Origin][#origin] for details. +All commits must be signed-off on. Please use `git commit -s` to do that. This serves as a confirmation that you have the right to submit your changes. See [Developer Certificate of Origin][origin] for details. [origin]: https://developercertificate.org/ -### Other tips +### Other tips You can increase the chance of your Pull Request being merged by: * having good test coverage * writing documentation * following PEP 8 for code formatting -* don't have [bandit](#bandit) complains -* writing [a good commit message](#commit-message) +* don't have [bandit][bandit] complains +* writing [a good commit message][commit-message] [commit-message]: https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html [bandit]: https://bandit.readthedocs.io -## Places and links +[places]: +## Places and links -* code is hosted on [Pagure](#pagure) (upstream GIT) -* web documentation can be found [here](#web-documentation) -* [issue tracker](#issues) -* [Pull Requests](#pull-requests) (PR) +* code is hosted on [Pagure][pagure] (upstream GIT) +* web documentation can be found [here][web-documentation] +* [issue tracker][issues] +* [Pull Requests][pull-requests] (PR) [pagure]: https://pagure.io/rpkg [issues]: https://pagure.io/rpkg/issues [pull-requests]: https://pagure.io/rpkg/pull-requests -## Testing process +[testing]: +## Testing process -Unittests are implemented to prevent issues and cover the code. When a new [Pull Request](#pull-requests) is created (or rebased), unit tests are triggered in [Jenkins](#jenkins). Test status is shown in the green (success) or red (failure) box on the Pull Request's page afterwards. +Unittests are implemented to prevent issues and cover the code. When a new [Pull Request][pull-requests] is created (or rebased), unit tests are triggered in [Jenkins][jenkins]. Test status is shown in the green (success) or red (failure) box on the Pull Request's page afterwards. To see detailed test results, open the URL (click on the colour box), select `default` configuration and then `Console Output`. -How to run unit tests manually or offline, see the [initial](#pagure) page or file `README.rst`. +How to run unit tests manually or offline, see the [initial][pagure] page or file `README.rst`. [jenkins]: https://jenkins-fedora-infra.apps.ocp.ci.centos.org/job/pyrpkg/ -## Release process +[release-process]: +## Release process A rpkg's release process could have two variants (both performed by maintainers): 1. A **new** rpkg's **release**. * the main version number is bumped, for example rpkg-1.63-4 --> rpkg-1.64-1 - * a new tarball is created (and additionally submitted to [PyPI](#pypi)) - * [documentation](#documentation) is generated - * a tarball is uploaded to [dist-git](#dist-git) + * a new tarball is created (and additionally submitted to [PyPI][pypi]) + * [documentation][documentation] is generated + * a tarball is uploaded to [dist-git][dist-git] * specfile is updated - * packages are built in [Koji](#koji) - * updates are created in [Bodhi](#bodhi) + * packages are built in [Koji][koji] + * updates are created in [Bodhi][bodhi] * tested by the community 2. A release of a **patch**. @@ -82,8 +85,8 @@ A rpkg's release process could have two variants (both performed by maintainers) * a minor version number is bumped, for example rpkg-1.63-4 --> rpkg-1.63-5 * a single or multiple fixes/features are taken (cherrypicked) from a rpkg's repository as patches. * specfile is updated - * packages are built in [Koji](#koji) - * updates are created in [Bodhi](#bodhi) + * packages are built in [Koji][koji] + * updates are created in [Bodhi][bodhi] * tested by the community Releases are irregular (usually once per few months). They depend on the number of unreleased features and fixes and the time since the last release. @@ -96,9 +99,10 @@ Patches are usually requested by customers or provided when there is an urgent i [bodhi]: https://bodhi.fedoraproject.org/updates/?packages=rpkg -## Documentation +[documentation]: +## Documentation -Rpkg contains the [web documentation](#web-documentation). It is generated from templates that are stored in the "doc" directory together with documentation-building scripts and Makefile. Anyone can contribute with changes, but final regeneration is done by the maintainer during a new version [release process](#release-process). +Rpkg contains the [web documentation][web-documentation]. It is generated from templates that are stored in the "doc" directory together with documentation-building scripts and Makefile. Anyone can contribute with changes, but final regeneration is done by the maintainer during a new version [release process][release-process]. Contributors can check results by regenerating documentation offline: @@ -109,7 +113,8 @@ Contributors can check results by regenerating documentation offline: [web-documentation]: https://pagure.io/docs/rpkg/ -## Code-review process +[code-review]: +## Code-review process 1. Motivation