Skip to content

PR Process

Jump to bottom
Chen Wang edited this page Oct 6, 2024 · 6 revisions

中文版

Sophgo related patch maintenance process

A development cycle of Linux starts with Merge Window (point A on the figure), which lasts for two weeks, and then begins to go through multiple RCs (Release Candidate), each lasting one week, normally 7 RCs. There is maybe one more RC8 if any serious problem happend.

We are currently mainly responsible for reviewing and collecting DTS changes under arch/riscv/boot/dts/sophgo/ and submitting Pull Requests to Upstream. Other driver-related content, such as dt-bindings, driver code, etc., in principle, are still collected and submitted by the maintainers in charge of the relevant subsystem. The patch collection and submission activities mentioned below generally refer to DTS changes under arch/riscv/boot/dts/sophgo/.

  • Starting from RC1 ("checkpoint 1" in the picture), "new feature" patches will no longer be accepted in this cycle. If there are bugfixes, they will be collected under branch "fixes" in https://github.com/sophgo/linux after they pass review.

  • Starting from RC1 ("checkpoint 2" in the picture), we will begin to collect "new feature" patches for the next cycle. After the patches pass review and are approved, we will collect it under branch "for-next" in https://github.com/sophgo/linux.

Note: The above "fixes"/"for-next" branch has been registered to linux-next and will be automatically pulled by the linux-next warehouse.

  • Starting from RC6 ("checkpoint 3" in the picture), we will collect DTS changes under arch/riscv/boot/dts/sophgo/ and submitting Pull Request to Upstream. The pre-condition of these changes will be collected is that the relevant bindings definitions and drivers are already in the kernel mainline, or have been reviewed and picked into the relevant next branch warehouse by corresponding subsystem maintainers.

Other:

Clone this wiki locally