PullRequest

PullRequest

Kokkos and KokkosKernels follow a develop-master branch workflow to conduct code development.

The develop branch is the progressive branch for new features, capabilities, and bug fixes. Developers should issue pull requests of their feature branches to the develop branch.

The master branch is considered the stable branch, as it is only updated periodically after extensive testing of the develop branch following the procedure documented in kokkos-kernels/doc/kokkos-promotion.txt. The master branch resides in the Trilinos repository.

Beginning code development

The starting point for development on any project is to attain the source code - clone the kokkos-kernels repository from Github and checkout the develop branch

git clone git@github.com:kokkos/kokkos-kernels.git
cd kokkos-kernels
git checkout develop

In addition, external users contributing to the repository must create their own fork of the repository for storing their feature branches (internal developers may choose to follow this workflow as well). Pull requests to the kokkos-kernels repo can then be made from the user's own fork.

Next, create a new feature branch from the develop branch to store code changes and start working

git checkout -b feature-branch

If working on a particular issue from kokkos-kernels' Github issue list, a typical naming convention for your branch is to name is "issue-<issue#>". For example, if you are working on issue number XYZ, you could create a branch "issue-XYZ".

Preparing to issue a pull request

When satisfied your code is ready to be considered for the kokkos-kernels repo, run through the following steps before submitting a pull request

1. Test your local code changes with multiple compiler and configuration options that are available, see the following wiki page for compiling and local testing instructions: Compiling

   For users with access to systems supported by the test_all_sandia script, run a spot-check via instructions from the wiki page: test_all_sandia script

   Note: All PRs require a posted message that documents passing results of a spot-check run of the test_all_sandia script. Users without access to systems can request testing from one of the internal developers.

2. Make sure your branch is up-to-date with the VOTD develop branch and free of merge conflicts

   The instructions below assume that the kokkos-kernels repository's remote is named origin

   cd <KOKKOSKERNELS_PATH>

   git checkout origin develop
   git pull
   git checkout feature-branch
   git merge develop

In the case of a long and messy commit history please squash commits using a git rebase. This may require a force push of the updated branch its github repository.

3. Make sure your branch is formatted with clang-format-16:

cd <KOKKOSKERNELS_PATH>
modified_files=$(git status -s | grep "^ M" | awk '{print $2}' | grep -E '\.(cpp|hpp)$')
podman run --rm -v "${PWD}":/src ghcr.io/cwpearson/clang-format-16:latest clang-format -i $modified_files

4. Push the updated branch to Github

   git checkout feature-branch
   git push origin

Pull request

Instructions for issuing a pull request are available on this Github link:

Specific requirements to kokkos-kernels:

• Pull requests should be issued to the develop branch
• Post a message with results from a spot-check run of the test_all_sandia script or request an internal developer to do so
• Request review of the PR from one of the internal developers
• Address comments from the reviewer, make any necessary code changes, and update the code in the pull request. Re-run testing after comments are satisfied