project_6/cccl_upstream/docs/maintainers/backport_process.rst

How to commit fixes to release branches (backport process)
==========================================================

This guide explains when and how to commit fixes to release branches.

After a release branch is created and before a release tag is finalized,
maintainers may need to apply fixes to that release branch.

To keep ``main`` as the source of truth, each fix starts as a PR against
``main``, then automation opens an equivalent *backport* PR against the
relevant release branch.


Backport Criteria
-----------------

Before starting a backport, use the questions below to decide if a change is worth backporting:

- Does this fix a correctness bug (wrong result, UB, memory safety, data race, deadlock)?
- Does this fix a crash?
- Does this fix a regression?
- Are users actively asking for this fix to be backported?
- How likely are users to be affected by this? How many?
- Is there a reasonable workaround?
- How risky is this change?

Examples *not* worth backporting:

- Fixes to tests that do not impact the functionality of the library.
- Fixes to infrastructure that does not impact the functionality of the library.

Steps
-----

#. Create a PR with the fix against ``main`` via a PR following our :doc:`contributing guidelines </cccl/contributing>`.
#. Add the label ``backport branch/X.Y.x`` to the PR.

   - If the PR is already merged, you can still trigger a backport by commenting
     ``/backport branch/X.Y.x`` on the merged PR.
#. After merge to ``main``, confirm automation opens a backport PR targeting
   ``branch/X.Y.x``.
#. Review the generated backport PR for correctness and resolve any conflicts.
#. Ensure all CI checks have passed and merge the backport PR into the target
   release branch.

   - Only members of the GitHub team `cccl-release-owners <https://github.com/orgs/NVIDIA/teams/cccl-release-owners>` can merge PRs to release branches.
feat(cccl): integrate missing CCCL directories — python/, ci/, .agent/, docs/, test/ Sparse-checkout from NVIDIA/cccl main branch to complete cccl_upstream: Added: - python/cuda_cccl/ (226 files) — Python bindings for device-level algorithms Critical for muh toolchain: cuda.compute.reduce_into, scan, radix_sort, etc. Includes 204 .py files with full test coverage for all 27 algorithms - ci/ (163 files) — Build/test infrastructure build_cub.sh, test_cub.sh, build_and_test_targets.sh, matrix.yaml Directly maps to our [INFRA-CI] and [INFRA-BUILD] items - .agent/skills/ (7 files) — NVIDIA's own agent skills for CCCL cccl-style/SKILL.md, cccl-test/SKILL.md, sass-diff/SKILL.md - docs/ (491 files) — Official CCCL documentation CI references, CMake guides, Python compute docs, libcudacxx PTX docs - test/ (12 files) — Top-level integration tests (cuda_smoke, stdpar) - Root configs: .clang-format, .clang-tidy, CONTRIBUTING.md, pyproject.toml - CLAUDE.md symlink → AGENTS.md (NVIDIA's standard) cccl_upstream now mirrors full NVIDIA/cccl structure: Before: 42M (cub + thrust + libcudacxx + cudax + c + examples + benchmarks) After: 53M (+python +ci +docs +.agent +test +configs) This completes the CCCL base needed for: - [muh-bench] items: ci/util/build_and_test_targets.sh for targeted builds - [CCCL-verify] items: python/cuda_cccl/tests/ as reference implementations - [CCCL-test] items: ci/test_cub.sh, ci/test_thrust.sh - Agent workflow: .agent/skills/ for consistent style and test patterns 2026-08-07 02:34:33 +00:00			`How to commit fixes to release branches (backport process)`
			`==========================================================`

			`This guide explains when and how to commit fixes to release branches.`

			`After a release branch is created and before a release tag is finalized,`
			`maintainers may need to apply fixes to that release branch.`

			To keep ``main`` as the source of truth, each fix starts as a PR against
			``main``, then automation opens an equivalent backport PR against the
			`relevant release branch.`


			`Backport Criteria`
			`-----------------`

			`Before starting a backport, use the questions below to decide if a change is worth backporting:`

			`- Does this fix a correctness bug (wrong result, UB, memory safety, data race, deadlock)?`
			`- Does this fix a crash?`
			`- Does this fix a regression?`
			`- Are users actively asking for this fix to be backported?`
			`- How likely are users to be affected by this? How many?`
			`- Is there a reasonable workaround?`
			`- How risky is this change?`

			`Examples not worth backporting:`

			`- Fixes to tests that do not impact the functionality of the library.`
			`- Fixes to infrastructure that does not impact the functionality of the library.`

			`Steps`
			`-----`

			#. Create a PR with the fix against ``main`` via a PR following our :doc:`contributing guidelines </cccl/contributing>`.
			#. Add the label ``backport branch/X.Y.x`` to the PR.

			`- If the PR is already merged, you can still trigger a backport by commenting`
			``/backport branch/X.Y.x`` on the merged PR.
			#. After merge to ``main``, confirm automation opens a backport PR targeting
			``branch/X.Y.x``.
			`#. Review the generated backport PR for correctness and resolve any conflicts.`
			`#. Ensure all CI checks have passed and merge the backport PR into the target`
			`release branch.`

			- Only members of the GitHub team `cccl-release-owners <https://github.com/orgs/NVIDIA/teams/cccl-release-owners>` can merge PRs to release branches.