You've already forked documentation
mirror of
https://github.com/armbian/documentation.git
synced 2026-01-06 10:13:36 -08:00
cf696f2296
* Update Process_Merge-Policy.md typo fix * more fixes Co-authored-by: Werner <EvilOlaf@users.noreply.github.com>
102 lines
4.0 KiB
Markdown
102 lines
4.0 KiB
Markdown
# Merge Policy
|
|
|
|
## Overview
|
|
|
|
_Note: This document is a Work In Progress and is subject to change. Definitions may be relocated to a seperate document in the future._
|
|
|
|
This policy is targeted for Maintainers for Lead Maintainers who have commit access to `master` branch. This document describes the tags needed for different merge types. See Definitions.
|
|
|
|
The types of code maintained fall into the following categories:
|
|
|
|
* Kernel
|
|
* U-Boot
|
|
* Build scripts
|
|
|
|
Kernel and U-Boot maintainers are usually grouped by SoC Architecture.
|
|
|
|
Supported boards will have the most scrunity with code review.
|
|
|
|
## U-Boot Patches
|
|
|
|
- Standard contributors provide _tested-by_ submitter (`armbianmonitor -u` with a fresh build).
|
|
- SoC maintainer may submit a PR reviewed by of the lead SoC maintainer only.
|
|
|
|
## Kernel Related Patches
|
|
|
|
### legacy and current branches
|
|
|
|
- DT changes reviewed by at least one person familiar with this SoC (lead maintainer or deputy), _tested-by_ the contributor who sends it (armbianmonitor).
|
|
- Trivial module activation doesn't matter.
|
|
|
|
### dev/edge branches
|
|
|
|
Constraints are at the discretion of the SoC mantainer. This builds are not expected to be stable.
|
|
|
|
## Armbian Build Scripts
|
|
|
|
This pertains to code used to build system images, OS configuration, and supporting packages (basically anything not u-boot or kernel source).
|
|
|
|
### lib scripts
|
|
|
|
* Requires at least one _Reviewed-by_.
|
|
|
|
### Configuration
|
|
|
|
#### board promotion
|
|
|
|
Boards have different levels of commitment / support. EOL, CSC, WIP, Supported. To promote a board from WIP to Supported an Acked-by from a Lead Maintainer is required.
|
|
|
|
#### kernel config
|
|
|
|
* Changes in legacy & current kernel config should provide at least _tested-by_ with `armbianmonitor -u`.
|
|
* Changes in edge are at the discretion of maintainer. No constraints.
|
|
|
|
#### kernel sources
|
|
|
|
Change kernel source repos, branches, versions can be very disruptive to stable builds. Sufficient communication should occur stable changes.
|
|
|
|
* U-Boot and kernel version bump for legacy and current requires _tested-by_ from Maintainers and/or testers on at least two different boards for the impacted platform.
|
|
* Kernel sources switch (legacy current) needs a discussion on forum or github or IRC and documented in PR and _Acked-by_ Lead Maintainer. These changes are risky and things can go terrible wrong here...
|
|
* edge source changes are at the discretion of the Lead Maintainer.
|
|
* Board family tweaks require at least _reviewed-by_.
|
|
|
|
#### packages
|
|
|
|
* minimum require _Acked-by_
|
|
|
|
## Definitions
|
|
|
|
### Code Review Terms
|
|
|
|
[click here for attribution to terms used below](https://lists.x.org/archives/xorg-devel/2009-October/003036.html)
|
|
|
|
#### Signed-off-by
|
|
|
|
Certifies that you wrote it or otherwise have the right to pass it on as a open-source patch.
|
|
|
|
#### Acked-by
|
|
|
|
If a person was not directly involved in the preparation or handling of a patch but wishes to signify and record their approval of it then they can arrange to have an Acked-by: line. Acked-by: does not necessarily indicate acknowledgement of the entire patch.
|
|
|
|
#### Tested-by
|
|
|
|
A Tested-by: tag indicates that the patch has been successfully tested (in some environment) by the person named. This tag informs maintainers that some testing has been performed, provides a means to locate testers for future patches, and ensures credit for the testers.
|
|
|
|
#### Reviewed-by
|
|
|
|
A Reviewed-by tag is a statement of opinion that the patch is an appropriate modification of the kernel without any remaining serious technical issues. Any interested reviewer (who has done the work) can offer a Reviewed-by tag for a patch.
|
|
|
|
### Other
|
|
|
|
#### Maintainer
|
|
|
|
An Individual designated to moderate, support and make decisions for a codebase or component. There can be multiple maintainers assigned to any given thing.
|
|
|
|
#### Lead Maintainer
|
|
|
|
A more experienced maintainer that will decide on high-impact and stategic changes and have final say in disputes. A lead maintainer may share or designiate responsibility to some or all components within their domain of responsibility.
|
|
|
|
#### SoC
|
|
|
|
System on-a-Chip.
|