| 1 | Policy for commits in aports
|
| 2 | ============================
|
| 3 |
|
| 4 | This document defines policy for organizing and titling commits for
|
| 5 | inclusion in aports.
|
| 6 |
|
| 7 | Glossary
|
| 8 | ---------
|
| 9 |
|
| 10 | Definition used for the following terms.
|
| 11 |
|
| 12 | ##### Repository
|
| 13 |
|
| 14 | Where the aport resides, it is the penultimate repository in the path of
|
| 15 | the aport.
|
| 16 |
|
| 17 | Example: `main/foo/APKBUILD`, `main` is the repository
|
| 18 |
|
| 19 | ##### Aport
|
| 20 |
|
| 21 | Directory inside the repository that contains a build recipe with metadata
|
| 22 | (APKBUILD) and auxiliary files.
|
| 23 |
|
| 24 | The name of the directory and the value of the variable `pkgname` in the
|
| 25 | build recipe **must** match.
|
| 26 |
|
| 27 | Example: `main/foo/APKBUILD`, `foo` is the aport
|
| 28 |
|
| 29 | ##### Commits
|
| 30 |
|
| 31 | Set of changes to files as recorded by git with other metadata like title,
|
| 32 | message and an autogenerated ID.
|
| 33 |
|
| 34 | ##### Merge Request
|
| 35 |
|
| 36 | Proposal of a set of commits to be merged into a branch of a repository.
|
| 37 |
|
| 38 | This is what maintainers review, and what Continuous Integration checks to
|
| 39 | guarantee it won't break anything.
|
| 40 |
|
| 41 | In Alpine Linux' aports terms this is commonly the `master` branch of the
|
| 42 | repo. Other branches like `3.X-stable` are used to push to released versions.
|
| 43 |
|
| 44 | Organizing
|
| 45 | ----------
|
| 46 |
|
| 47 | Commits should be split by function and what aport they change, one commit
|
| 48 | per aport changed, and one commit per type of change.
|
| 49 |
|
| 50 | Commits that are related to the same aport or are closely related must be
|
| 51 | under the same Merge Request.
|
| 52 |
|
| 53 | Exceptions to these organization rules may apply depending on the situation,
|
| 54 | as noted below.
|
| 55 |
|
| 56 | Commit types
|
| 57 | ------------
|
| 58 |
|
| 59 | Different sets of changes in a commit award a different type that has a
|
| 60 | distinct template, rules and exceptions to follow when organizing and titling.
|
| 61 |
|
| 62 | ---
|
| 63 |
|
| 64 | ### Upgrade
|
| 65 |
|
| 66 | Increases the value of `pkgver`, and sets the value of `pkgrel` to 0.
|
| 67 |
|
| 68 | ###### Template
|
| 69 |
|
| 70 | - `$repository/$pkgname: upgrade to $pkgver`
|
| 71 |
|
| 72 | Example: `main/foo: upgrade to 2.0.0`
|
| 73 |
|
| 74 | ###### Rules
|
| 75 |
|
| 76 | One commit per upgraded aport.
|
| 77 |
|
| 78 | ###### Exceptions
|
| 79 |
|
| 80 | Upgrading lots of aports that are maintained upstream in lockstep (same version
|
| 81 | and released at the same time) can be all in the same commit
|
| 82 |
|
| 83 | Example: KDE Plasma Framework
|
| 84 |
|
| 85 | ---
|
| 86 |
|
| 87 | ### Downgrade
|
| 88 |
|
| 89 | Decreases the value of `pkgver`, and increases the value of `pkgrel` by 1 in
|
| 90 | relation to the value of `pkgrel` before the last upgrade.
|
| 91 |
|
| 92 | ###### Template
|
| 93 |
|
| 94 | - `$repository/$pkgname: downgrade to $pkgver`
|
| 95 |
|
| 96 | Example: `main/foo: downgrade to 1.9.8`
|
| 97 |
|
| 98 | ###### Rules
|
| 99 |
|
| 100 | One commit per downgraded aport.
|
| 101 |
|
| 102 | ---
|
| 103 |
|
| 104 | ### Move
|
| 105 |
|
| 106 | Moves an aport from one repository to another.
|
| 107 | No change to value of `pkgrel` is necessary unless there are other changes
|
| 108 | in addition to the move.
|
| 109 |
|
| 110 | ###### Template
|
| 111 |
|
| 112 | - `$newrepository/$pkgname: move from $oldrepository`
|
| 113 |
|
| 114 | Example: `community/foo: move from main`
|
| 115 |
|
| 116 | ###### Rules
|
| 117 |
|
| 118 | One commit per moved aport.
|
| 119 |
|
| 120 | ---
|
| 121 |
|
| 122 | ### Rename
|
| 123 |
|
| 124 | Renames an aport.
|
| 125 |
|
| 126 | ###### Template
|
| 127 |
|
| 128 | - `$repository/$newpkgname: rename from $oldpkgname`
|
| 129 |
|
| 130 | Example: `community/bar: rename from foo`
|
| 131 |
|
| 132 | ###### Rules
|
| 133 |
|
| 134 | One commit per renamed aport.
|
| 135 |
|
| 136 | ---
|
| 137 |
|
| 138 | ### Add
|
| 139 |
|
| 140 | Introduces a new aport.
|
| 141 |
|
| 142 | ###### Template
|
| 143 |
|
| 144 | - `$repository/$pkgname: new aport`
|
| 145 |
|
| 146 | Example: `testing/bar: new aport`
|
| 147 |
|
| 148 | ###### Rules
|
| 149 |
|
| 150 | One commit per aport introduced.
|
| 151 |
|
| 152 | ---
|
| 153 |
|
| 154 | ### Remove
|
| 155 |
|
| 156 | Removes an aport from aports altogether.
|
| 157 |
|
| 158 | #### Template
|
| 159 |
|
| 160 | - `$repository/$pkgname: remove`
|
| 161 |
|
| 162 | Example: `community/baz: remove`
|
| 163 |
|
| 164 | #### Rules
|
| 165 |
|
| 166 | One commit per removed aport.
|
| 167 |
|
| 168 | ---
|
| 169 |
|
| 170 | ### Rebuilds
|
| 171 |
|
| 172 | Only increasing the value of `pkgrel` by 1.
|
| 173 |
|
| 174 | #### Template
|
| 175 |
|
| 176 | - `$repository/$pkgname: rebuild <reason-if-exists>`
|
| 177 |
|
| 178 | Example: `community/foo: rebuild`
|
| 179 |
|
| 180 | #### Rules
|
| 181 |
|
| 182 | One commit per rebuilt aport.
|
| 183 |
|
| 184 | #### Exceptions
|
| 185 |
|
| 186 | When various aports need to be rebuilt for the same reason the commit can
|
| 187 | hold all `Rebuilds` but split instead by repository.
|
| 188 |
|
| 189 | Example: `community/*: rebuild for so:libfoo.so.2`
|
| 190 |
|
| 191 | ---
|
| 192 |
|
| 193 | ### Addition of maintainership
|
| 194 |
|
| 195 | Adding yourself as maintainer.
|
| 196 |
|
| 197 | #### Template
|
| 198 |
|
| 199 | - `$repository/$pkgname: take over maintainership`
|
| 200 |
|
| 201 | Example: `community/foo: take over maintainership`
|
| 202 |
|
| 203 | #### Rules
|
| 204 |
|
| 205 | One commit per aport assumed maintainership of.
|
| 206 |
|
| 207 | ---
|
| 208 |
|
| 209 | ### Removal of maintainership
|
| 210 |
|
| 211 | Removing yourself as maintainer.
|
| 212 |
|
| 213 | #### Template
|
| 214 |
|
| 215 | - `$repository/$pkgname: drop maintainership`
|
| 216 |
|
| 217 | Example: `community/foo: drop maintainership`
|
| 218 |
|
| 219 | #### Rules
|
| 220 |
|
| 221 | One commit per aport maintainership is removed from.
|
| 222 |
|
| 223 | #### Exceptions
|
| 224 |
|
| 225 | When removing maintainership from all aports you maintain, the commit can
|
| 226 | hold all maintainership removals but instead be split by repository.
|
| 227 |
|
| 228 | Example: `community/*: drop maintainership`
|
| 229 |
|
| 230 | |
| 231 | Missing improvements
|
| 232 | Also missing tree-wide changes like usage of abuild-meson instead of meson
|
| 233 |
|
| 234 |
|
| 235 | ---
|
| 236 |
|
| 237 | ### Other
|
| 238 |
|
| 239 | Any set of changes not specified above falls under this type.
|
| 240 |
|
| 241 | #### Template
|
| 242 |
|
| 243 | If the commit changes an aport:
|
| 244 |
|
| 245 | - `$repository/$pkgname: <action>`
|
| 246 |
|
| 247 | If the commit changes anything else in the repository:
|
| 248 |
|
| 249 | - `$directory_or_file: <action>`
|
| 250 | - If the file is inside a directory use the directory, if inside a file use the name of the file
|
| 251 |
|
| 252 | `<action>` is what is the commit is doing. Be **short** and **direct**.
|
| 253 |
|
| 254 | Examples:
|
| 255 |
|
| 256 | - `main/foo: fix policy violations`
|
| 257 | - `scripts/: enable compilation under mips64el`
|
| 258 |
|
| 259 | #### Rules
|
| 260 |
|
| 261 | It is **essential** to include reasoning for the changes in the body of the
|
| 262 | commit.
|
| 263 |
|
| 264 | Universal Title writing rules
|
| 265 | -----------------------------
|
| 266 |
|
| 267 | Applies to all commits, regardless of type.
|
| 268 |
|
| 269 | ### Imperative, Present Tense
|
| 270 |
|
| 271 | Use the Present Tense and the Imperative mood
|
| 272 |
|
| 273 | Examples:
|
| 274 |
|
| 275 | - `main/foo: remove stale patches`
|
| 276 | - `community/bar: patch CVE-YYYY-XXXXX`
|
| 277 | - `testing/baz: fix policy violations`
|
| 278 |
|
| 279 | ### Lowercase, No dot
|
| 280 |
|
| 281 | Text after the colon must start in lowercase and have no dot at the end.
|
| 282 |
|
| 283 | ### Direct, Short
|
| 284 |
|
| 285 | Focus on **what** the commit does and use as few words as possible.
|
| 286 |
|
| 287 | If possible also tell **why**.
|
| 288 |
|
| 289 | Good examples:
|
| 290 |
|
| 291 | - `main/foo: fix build under gcc-10`
|
| 292 | - `fix build` is **what**
|
| 293 | - `under gcc-10` is **why**
|
| 294 | - `main/foo: disable support for X`
|
| 295 | - `disable support for X` is **what**
|
| 296 | - `main/foo: add fish completion`
|
| 297 | - `add fish completion` is **what**
|
| 298 | - `main/foo: enable on x86`
|
| 299 | - `enable on x86` is **what**
|
| 300 | - `main/foo: rebuild for so:foo.so.2`
|
| 301 | - `rebuild` is **what**
|
| 302 | - `for so:foo.so.2` is **why**
|
| 303 |
|
| 304 | They are short and concise, they tell **what** the commit did. If given
|
| 305 | the opportunity also tell **why**.
|
| 306 |
|
| 307 | The **how** and a clear **why** is handled by the commit body and changes.
|
| 308 |
|
| 309 | ### Assume basic knowledge, Avoid unnecessary explanations
|
| 310 |
|
| 311 | The reader does not need to be told how the complex details of something work,
|
| 312 | just that it was the reason the change was done.
|
| 313 |
|
| 314 | Example:
|
| 315 |
|
| 316 | Don't tell the user how sonames work and how an ELF binary finds libraries
|
| 317 | to load via the soname, just tell the soname has changed and thus a rebuild was
|
| 318 | required.
|