|
@@ -2,8 +2,9 @@
|
2
|
2
|
(See <http://wiki.openwrt.org/doc/devel/packages> for overall format and construction)
|
3
|
3
|
|
4
|
4
|
|
5
|
|
-All packages you commit or submit by pull-request should follow these simple guidelines:
|
|
5
|
+### Basic guidelines
|
6
|
6
|
|
|
7
|
+All packages you commit or submit by pull-request should follow these simple guidelines:
|
7
|
8
|
* Package a version which is still maintained by the upstream author.
|
8
|
9
|
* Will be updated regularly to maintained and supported versions.
|
9
|
10
|
* Have no dependencies outside the OpenWrt core packages or this repository feed.
|
|
@@ -11,10 +12,10 @@ All packages you commit or submit by pull-request should follow these simple gui
|
11
|
12
|
* Do NOT use a rolling source file (e.g. foo-latest.tar.gz) or the head of a branch as source for the package since that would create unpredictable builds which change over time.
|
12
|
13
|
* Best of all -- it works as expected!
|
13
|
14
|
|
14
|
|
-Makefile contents should contain:
|
|
15
|
+#### Makefile contents should contain:
|
15
|
16
|
|
16
|
17
|
* An up-to-date copyright notice. Use OpenWrt if no other present or supply your own.
|
17
|
|
-* A (PKG_)MAINTAINER definition listing either yourself or another person in the field.
|
|
18
|
+* A (PKG_)MAINTAINER definition listing either yourself or another person in the field.
|
18
|
19
|
(E.g.: PKG_MAINTAINER:= Joe D. Hacker `<jdh@jdhs-email-provider.org`>)
|
19
|
20
|
* A PKG_LICENSE tag declaring the main license of the package.
|
20
|
21
|
(E.g.: PKG_LICENSE:=GPL-2.0+) Please use SPDX identifiers if possible (see list at the bottom).
|
|
@@ -22,27 +23,47 @@ Makefile contents should contain:
|
22
|
23
|
(E.g.: PKG_LICENSE_FILES:=COPYING)
|
23
|
24
|
* PKG_RELEASE should be initially set to 1 or reset to 1 if the software version is changed. You should increment it if the package itself has changed. For example, modifying a support script, changing configure options like --disable* or --enable* switches, or if you changed something in the package which causes the resulting binaries to be different. Changes like correcting md5sums, changing mirror URLs, adding a maintainer field or updating a comment or copyright year in a Makefile do not require a change to PKG_RELEASE.
|
24
|
25
|
|
25
|
|
-Commits in your pull-requests should:
|
|
26
|
+#### Commits in your pull-requests should:
|
26
|
27
|
|
27
|
|
-* Have a useful description prefixed with the package name
|
|
28
|
+* Have a useful description prefixed with the package name
|
28
|
29
|
(E.g.: "foopkg: Add libzot dependency")
|
29
|
|
-* Include Signed-off-by in the comment
|
|
30
|
+* Include Signed-off-by in the comment
|
30
|
31
|
(See <https://dev.openwrt.org/wiki/SubmittingPatches#a10.Signyourwork>)
|
31
|
32
|
|
32
|
|
-If you have commit access:
|
|
33
|
+### Advice on pull requests:
|
|
34
|
+
|
|
35
|
+Pull requests are the easiest way to contribute changes to git repos at Github. They are the preferred contribution method, as they offer a nice way for commenting and amending the proposed changes.
|
|
36
|
+
|
|
37
|
+* You need a local "fork" of the Github repo.
|
|
38
|
+* Use a "feature branch" for your changes. That separates the changes in the pull request from your other changes and makes it easy to edit/amend commits in the pull request. Workflow using "feature_x" as the example:
|
|
39
|
+ - Update your local git fork to the tip (of the master, usually)
|
|
40
|
+ - Create the feature branch with `git checkout -b feature_x`
|
|
41
|
+ - Edit changes and commit them locally
|
|
42
|
+ - Push them to your Github fork by `git push -u origin feature_x`. That creates the "feature_x" branch at your Github fork and sets it as the remote of this branch
|
|
43
|
+ - When you now visit Github, you should see a proposal to create a pull request
|
|
44
|
+
|
|
45
|
+* If you later need to add new commits to the pull request, you can simply commit the changes to the local branch and then use `git push` to automatically update the pull request.
|
|
46
|
+
|
|
47
|
+* If you need to change something in the existing pull request (e.g. to add a missing signed-off-by line to the commit message), you can use `git push -f` to overwrite the original commits. That is easy and safe when using a feature branch. Example workflow:
|
|
48
|
+ - Checkout the feature branch by `git checkout feature_x`
|
|
49
|
+ - Edit changes and commit them locally. If you are just updating the commit message in the last commit, you can use `git commit --amend` to do that
|
|
50
|
+ - If you added several new commits or made other changes that require cleaning up, you can use `git rebase -i HEAD~X` (X = number of commits to edit) to possibly squash some commits
|
|
51
|
+ - Push the changed commits to Github with `git push -f` to overwrite the original commits in the "feature_x" branch with the new ones. The pull request gets automatically updated
|
|
52
|
+
|
|
53
|
+### If you have commit access:
|
33
|
54
|
|
34
|
55
|
* Do NOT use git push --force.
|
35
|
56
|
* Do NOT commit to other maintainer's packages without their consent.
|
36
|
57
|
* Use Pull Requests if you are unsure and to suggest changes to other maintainers.
|
37
|
58
|
|
38
|
|
-Gaining commit access:
|
|
59
|
+#### Gaining commit access:
|
39
|
60
|
|
40
|
61
|
* We will gladly grant commit access to responsible contributors who have made
|
41
|
62
|
useful pull requests and / or feedback or patches to this repository or
|
42
|
63
|
OpenWrt in general. Please include your request for commit access in your
|
43
|
64
|
next pull request or ticket.
|
44
|
65
|
|
45
|
|
-Release Branches:
|
|
66
|
+### Release Branches:
|
46
|
67
|
|
47
|
68
|
* Branches named "for-XX.YY" (e.g. for-14.07) are release branches.
|
48
|
69
|
* These branches are built with the respective OpenWrt release and are created
|
|
@@ -51,9 +72,8 @@ Release Branches:
|
51
|
72
|
* Do NOT add new packages and do NOT do major upgrades of packages here.
|
52
|
73
|
* If you are unsure if your change is suitable, please use a pull request.
|
53
|
74
|
|
54
|
|
-####Common LICENSE tags (short list)
|
|
75
|
+### Common LICENSE tags (short list)
|
55
|
76
|
(Complete list can be found at: <http://spdx.org/licenses>)
|
56
|
|
-####
|
57
|
77
|
|
58
|
78
|
| Full Name | Identifier |
|
59
|
79
|
|---|:---|
|