CONTRIBUTING.md

   1 # Contributing Guidelines
   2
   3 Ref: <https://openwrt.org/docs/guide-developer/packages> for overall format and construction
   4
   5 ## Basic guidelines
   6
   7 All packages you commit or submit by pull-request should follow these simple
   8 guidelines:
   9
  10 - Package a version which is still maintained by the upstream author and will
  11   be updated regularly with supported versions.
  12 - Have no dependencies outside the OpenWrt core packages or this repository
  13   feed.
  14 - Have been tested to compile with the correct includes and dependencies.
  15   Please also test with "Compile with full language support" found under
  16   "General Build Settings" set if language support is relevant to your package.
  17 - Best of all -- it works as expected!
  18
  19 ## Package Sources (archives and repositories)
  20
  21 - PKG_SOURCE should reference the smallest available archive. In order of
  22   preference: xz (most compressed), bzip2, gz and zip. As a last resort,
  23   downloads from source repositories can be used.
  24 - PKG_SOURCE_URL should link to an official release archive. Use of HTTPS&#x3A;
  25   is preferred. If a source archive is not available, a locally generated
  26   archive fetched using git, svn, cvs or in rare circumstances, hg or bzr.
  27 - Convenience macros for popular mirrors are defined. Using these macros will
  28   make your package downloads more robust by mapping to a list of possible
  29   source mirrors for archive availability.
  30   - @SF - Sourceforge (downloads.sourceforge.net) with 5 retries due to
  31     re-directs
  32   - @GITHUB - Github (raw.githubusercontent.com) with 5 retries due to
  33     re-directs
  34   - @GNU - 8 regional servers
  35   - @GNOME - 8 regional servers
  36   - @SAVANNAH - 8 regional servers
  37   - @APACHE - 8 regional servers
  38   - @KERNEL - Linux kernel archives & mirrors
  39 - Please _DO NOT_ use an archive which changes over time. A version labeled
  40   "latest" is not constant each download. Also, using the head of a branch will
  41   create unpredictable results which can be different each build.
  42
  43 ### Makefile contents should contain
  44
  45 - Provide an up-to-date Copyright notice or **none**. Copyright should not be
  46   assigned to OpenWrt unless you are explicitly requested by or working under
  47   contract to OpenWrt. Assigning a Copyright to yourself or organization you
  48   represent is acceptable.
  49 - A (PKG\_)MAINTAINER definition listing either yourself and/or another person
  50   responsible for this package (E.g.: PKG_MAINTAINER:= Joe D. Hacker
  51   `<jdh@jdhs-email-provider.org`>). Listing multiple maintainers is encouraged in
  52   order to keep the package active and up-to-date. Leaving this blank will also
  53   be accepted, however the review process may not be as quick as one with a
  54   maintainer.
  55 - A PKG_LICENSE tag declaring the main license of the package.  (E.g.:
  56   PKG_LICENSE:=GPL-2.0-or-later) Please use SPDX identifiers if possible (see
  57   list at the bottom).
  58 - An optional PKG_LICENSE_FILES tag including the filenames of the
  59   license-files in the source-package.  (E.g.: PKG_LICENSE_FILES:=COPYING)
  60 - PKG_RELEASE should be initially set to 1 or reset to 1 if the software
  61   version is changed. You should increment it if the package itself has
  62   changed. For example, modifying a support script, changing configure options
  63   like --disable_ or --enable\_ switches, or if you changed something in the
  64   package which causes the resulting binaries to be different. Changes like
  65   correcting md5sums, changing mirror URLs, adding a maintainer field or updating
  66   a comment or copyright year in a Makefile do not require a change to
  67   PKG_RELEASE.
  68 - Avoid reuse of PKG_NAME in call, define and eval lines to improve
  69   readability.
  70
  71 ### Commits in your pull-requests should
  72
  73 - Have a useful description prefixed with the package name (E.g.: "foopkg: Add
  74   libzot dependency")
  75 - Include Signed-off-by tag in the commit comments.  See: [Sign your
  76   work](https://openwrt.org/submitting-patches#sign_your_work)
  77
  78 ## Advice on pull requests
  79
  80 Pull requests are the easiest way to contribute changes to git repos at Github.
  81 They are the preferred contribution method, as they offer a nice way for
  82 commenting and amending the proposed changes.
  83
  84 - You need a local "fork" of the Github repo.
  85
  86 - Use a "feature branch" for your changes. That separates the changes in the
  87   pull request from your other changes and makes it easy to edit/amend commits
  88   in the pull request. Workflow using "feature_x" as the example:
  89   - Update your local git fork to the tip (of the master, usually)
  90   - Create the feature branch with `git checkout -b feature_x`
  91   - Edit changes and commit them locally
  92   - Push them to your Github fork by `git push -u origin feature_x`. That
  93     creates the "feature_x" branch at your Github fork and sets it as the
  94     remote of this branch
  95   - When you now visit Github, you should see a proposal to create a pull
  96     request
  97
  98 - If you later need to add new commits to the pull request, you can simply
  99   commit the changes to the local branch and then use `git push` to
 100   automatically update the pull request.
 101
 102 - If you need to change something in the existing pull request (e.g. to add a
 103   missing signed-off-by line to the commit message), you can use `git push -f`
 104   to overwrite the original commits. That is easy and safe when using a feature
 105   branch. Example workflow:
 106   - Checkout the feature branch by `git checkout feature_x`
 107   - Edit changes and commit them locally. If you are just updating the commit
 108     message in the last commit, you can use `git commit --amend` to do that
 109   - If you added several new commits or made other changes that require
 110     cleaning up, you can use `git rebase -i HEAD~X` (X = number of commits to
 111     edit) to possibly squash some commits
 112   - Push the changed commits to Github with `git push -f` to overwrite the
 113     original commits in the "feature_x" branch with the new ones. The pull
 114     request gets automatically updated
 115
 116 ## If you have commit access
 117
 118 - Do NOT use git push --force.
 119 - Do NOT commit to other maintainer's packages without their consent.
 120 - Use Pull Requests if you are unsure and to suggest changes to other
 121   maintainers.
 122
 123 ### Gaining commit access
 124
 125 - We will gladly grant commit access to responsible contributors who have made
 126   useful pull requests and / or feedback or patches to this repository or
 127   OpenWrt in general. Please include your request for commit access in your next
 128   pull request or ticket.
 129
 130 ## Release Branches
 131
 132 - Old stable branches were named after the following pattern "for-XX.YY" (e.g.
 133   for-14.07) before the LEDE split.  During the LEDE split there was only one
 134   release branch with the name "lede-17.01".  After merging the LEDE fork with
 135   OpenWrt the release branches are named according to the following pattern
 136   "openwrt-XX.YY" (e.g. openwrt-18.06).
 137 - These branches are built with the respective OpenWrt release and are created
 138   during the release stabilisation phase.
 139 - Please ONLY cherry-pick or commit security and bug-fixes to these branches.
 140 - Do NOT add new packages and do NOT do major upgrades of packages here.
 141 - If you are unsure if your change is suitable, please use a pull request.
 142
 143 ## Common LICENSE tags (short list)
 144
 145 (Complete list can be found at: <https://spdx.org/licenses>)
 146
 147 | Full Name                                        | Identifier               |
 148 | ------------------------------------------------ | :----------------------- |
 149 | Apache License 1.0                               | Apache-1.0               |
 150 | Apache License 1.1                               | Apache-1.1               |
 151 | Apache License 2.0                               | Apache-2.0               |
 152 | Artistic License 1.0                             | Artistic-1.0             |
 153 | Artistic License 1.0 w/clause 8                  | Artistic-1.0-cl8         |
 154 | Artistic License 1.0 (Perl)                      | Artistic-1.0-Perl        |
 155 | Artistic License 2.0                             | Artistic-2.0             |
 156 | BSD 2-Clause "Simplified" License                | BSD-2-Clause             |
 157 | BSD 2-Clause FreeBSD License                     | BSD-2-Clause-FreeBSD     |
 158 | BSD 2-Clause NetBSD License                      | BSD-2-Clause-NetBSD      |
 159 | BSD 3-Clause "New" or "Revised" License          | BSD-3-Clause             |
 160 | BSD with attribution                             | BSD-3-Clause-Attribution |
 161 | BSD 3-Clause Clear License                       | BSD-3-Clause-Clear       |
 162 | BSD 4-Clause "Original" or "Old" License         | BSD-4-Clause             |
 163 | BSD-4-Clause (University of California-Specific) | BSD-4-Clause-UC          |
 164 | BSD Protection License                           | BSD-Protection           |
 165 | GNU General Public License v1.0 only             | GPL-1.0-only             |
 166 | GNU General Public License v1.0 or later         | GPL-1.0-or-later         |
 167 | GNU General Public License v2.0 only             | GPL-2.0-only             |
 168 | GNU General Public License v2.0 or later         | GPL-2.0-or-later         |
 169 | GNU General Public License v3.0 only             | GPL-3.0-only             |
 170 | GNU General Public License v3.0 or later         | GPL-3.0-or-later         |
 171 | GNU Lesser General Public License v2.1 only      | LGPL-2.1-only            |
 172 | GNU Lesser General Public License v2.1 or later  | LGPL-2.1-or-later        |
 173 | GNU Lesser General Public License v3.0 only      | LGPL-3.0-only            |
 174 | GNU Lesser General Public License v3.0 or later  | LGPL-3.0-or-later        |
 175 | GNU Library General Public License v2 only       | LGPL-2.0-only            |
 176 | GNU Library General Public License v2 or later   | LGPL-2.0-or-later        |
 177 | Fair License                                     | Fair                     |
 178 | ISC License                                      | ISC                      |
 179 | MIT License                                      | MIT                      |
 180 | No Limit Public License                          | NLPL                     |
 181 | OpenSSL License                                  | OpenSSL                  |
 182 | X11 License                                      | X11                      |
 183 | zlib License                                     | Zlib                     |
 184
 185 ## Continuous Integration
 186
 187 To simplify review and require less human resources, a CI tests all packages.
 188 Passing CI tests are not a hard requirement but a good indicator what the
 189 Buildbots will think about the proposed patch.
 190
 191 The CI builds modified packages for multiple architectures using the latest
 192 snapshot SDK. For supported architectures (`aarch64_generic`,
 193 `arm_cortex-a15_neon-vfpv4`, `i386_pentium4` and `x86_64`) an additional
 194 runtime test is executed. A running OpenWrt is simulated which tries to install
 195 created packages and runs a script called `test.sh` located next to the package
 196 Makefile. The script is executed with the two arguments `PKG_NAME` and
 197 `PKG_VERSION`. The `PKG_NAME` can be used to distinguish package variants, e.g.
 198 `foobar` vs. `foobar-full`. The `PKG_VERSION` can be used for a trivial test
 199 checking if `foobar --version` prints the correct version. `PKG_VERSION` is the
 200 OpenWrt version and therefore includes the `PKG_RELEASE`, which isn't usually
 201 part of the running programs version.
 202
 203 The following snippet show a script that tests different binaries, depending
 204 what IPK package was installed. The `gpsd` Makefile produces both a `gpsd` and
 205 a `gpsd-clients` IPK package.
 206
 207 ```shell
 208  #!/bin/sh
 209
 210 case "$1" in
 211     "gpsd")
 212         gpsd -V 2>&1 | grep "$2"
 213         ;;
 214     "gpsd-clients")
 215         cgps -V 2>&1 | grep "$2"
 216         ;;
 217 esac
 218 ```