We warmly welcome and appreciate contributions from the community! By participating you agree to the code of conduct.

• Gather input early and often rather than waiting until the end.
  • Have in-person conversations.
  • Regularly share your branch of work.
  • Consider making a draft PR.
  • Pair as needed.
• Prefer short names based on context such as: file vs. database_file
  • People will be familiar with the code, so err on the side of brevity but avoid extremes.
• Generally follow surrounding code style and conventions. Use make lint.
• Have tests including unit and end-to-end.
• Resources:
  • Effective Go
  • Go Code Review Comments
  • Practical Go
  • The Go Memory Model
  • Protocol Buffers Syle Guide
  • BASH Style Guide
  • Refactoring by Martin Fowler including the Refactoring website.

Optimize the review experience for others. The goal is to make reviewing PRs easy for others. Example PR.

• Ensure PRs are single focused. If more work is needed specify followup PRs, as multiple PRs per feature is fine.
• Avoid one large PR that is hard to review. Consider multiple smaller scoped PRs.
• Ensure PRs are completed before submitting.
  • Ensure all unit and end-to-end tests are written.
  • A successful test pipeline has been run.
  • Make a draft PR for early feedback.
• Ensure the PR description is detailed.
  • Include a link to the test pipeline for others to review.
• Create individual logical commits with detailed descriptions.
  • Try to keep pre-factors and code motion to their own commits.
• Minimize lots of commits after submitting.
• Minimize morphing PR branches into WIP branches.
• Only merge PRs once at least one other person who did not work on the code approves it.
• Squash all relevant commits and do a "Rebase and merge". Do not perform a "merge commit" or "squash and merge".

• Sign our Contributor License Agreement.

• Fork the gpupgrade repository on GitHub.

• Clone the repository.

• Follow the README to set up your environment and run the tests.

• Create a change

  • Create a topic branch.

  • Make commits as logical units for ease of reviewing.

  • Try and follow similar coding styles as found throughout the code base.

  • Rebase with main often to stay in sync with upstream.

  • Add appropriate tests and view coverage with make coverage.

  • Ensure a well written commit message as explained here and here.

  • Format code with make format.

  • Address any linter issues with make lint.

• Submit a pull request (PR).

  • Create a pull request from your fork.

  • We will create a test pipeline which runs additional acceptance tests based on your branch.

  • Address PR feedback with fixup and/or squash commits.

    git add .
    git commit --fixup <commit SHA> 
        Or
    git commit --squash <commit SHA>
    

  • Once approved, before merging into main squash your fixups with:

    git rebase -i --autosquash origin/main
    git push --force-with-lease $USER <my-feature-branch>
    

• Follow Google's Code Review Guidelines
• PR comments should have technical explanations.
• Avoid “I prefer it this way”. See Principles Section.
• Avoid these Toxic Behaviors (video)
• Use Github's "Request changes" very sparingly. This indicates that there are critical blockers that absolutely must change before approval.
• Use Github's “Start a review” feature to submit multiple comments into a single review.
• Address PR comments with fixup or squash commits. This makes it easier for the review to see what changed.
  • Ideally wait until the PR has been approved to squash tehse commits, but sometimes it might be cleaner and easier to follow to combine them earlier.
  • Rebasing your PR with main is good practice.
• Use Github’s “Resolve Conversation” button to indicate you addressed the feedback. There is no need for a comment unless you deviated from the reviewer's specific feedback.
• Tag an individual person if you want a review from them, otherwise tag the "Upgrade" team. If you want a re-review, tag a specific person in a comment to send them a notification.

Connect with Greenplum on:

• Slack
• gpdb-dev mailing list