Skip to content

Maintainer Policies and Standards

Jump to bottom
John edited this page Mar 11, 2020 · 9 revisions

Maintainers of PC2 code -- meaning, those people who have full access rights to the master pc2ccs/pc2v9 repo -- have a special responsibility to establish and conform to a well-defined set of policies and procedures both for adding code/modifications to the system themselves as well as for handling Pull Requests from outside developers in a uniform way. This page presents a list of policies and practices that should be followed by all PC2V9 maintainers.

Policy 1 - The only change to the develop/master branch is via a PR/merge.

Policy 2 - Test issue fixes against the current develop head before submitting a PR.

Policy 3 - Do not push anything other than a specific issue branches to your fork

Typical Development Procedures

  • Practice 1A: do not merge any branch into develop on a fork, or into develop on a local repo where it can be pushed to a fork.

    This can cause the situation where multiple issues in a working branch get pushed upstream, leading to PRs containing multiple issues.

  • Practice 1B: do not push anything up to a fork except an issue-specific "topic" ("feature") branch.

    Again, this can cause the situation where multiple issues are contained in a single PR.

  • Practice 2A: Test locally against the current develop branch

    ** Sync your GitHub fork with the pc2ccs/pc2v9 repo. See this page, but note you should use "develop" instead of "master" as the branch you are sync'ing with.

    ** Push the updated local repo up to your PC2v9 fork:git push.

    ** Check out your issue branch:git checkout b_issue#_issue_description.

    ** Rebase your branch onto the tip of the develop branch:git rebase develop.

    ** Fix any merge conflicts. See this page for insights into resolving merge conflicts.

    ** Test that the results are working correctly (including running all JUnit tests).

  • Practice 2B: Push the issue branch to your fork:git push --force. (The "--force" is to deal with any rebasing that happened when the sync was done).

    • Practice 1C: Submit an issue-specific PR for every issue.

    Every change to the system should be developed on a branch, tested against develop (see below), and pushed up to the developer's local fork. A PR should then be submitted requesting review/acceptance of the change. Another maintainer should review the PR and then either accept it (and merge it to develop in the pc2ccs/pc2v9 master repo), or comment indicating why it shouldn't be accepted.

  • Practice 2C: Submit a PR for the issue.

    ** Go to the GitHub page for your fork.

    ** On the "Code" tab, locate your pushed branch and click "Compare & pull request"

    ** Click the "base:master" dropdown and select "develop".

    ** Fill in the PR template.

    ** Click "Create Pull Request"

PC2 Logo

Clone this wiki locally