Working with pull requests - deegree/deegree3 GitHub Wiki

Use of pull requests within the deegree project

To make best use of GitHub's fork and pull development model, we use the following procedure:

• No major changes are pushed into the main repositories of the deegree group directly
• Everybody is invited to fork the deegree repositories on GitHub
• If you want a code enhancement to be included, please prepare a pull request
• deegree's technical management committee (TMC) will review pending pull requests and merge the ones that are ready to go into the main repository. This is part of the biweekly TMC meetings.
• Everybody is invited to join the TMC meetings to talk about the pull requests, especially the actual implementers!

Creating your own pull request

In order to create a pull request for a new feature or a bugfix it is advisable to follow these steps:

• Create your own fork on GitHub

• Add the original deegree repository as remote to your local clone, eg. git remote add deegree git://github.com/deegree/deegree3.git for the deegree3 repository

• create a feature branch based on the current deegree main branch:

  • git checkout deegree/main
  • git checkout -b <my-new-branch-name>

• Implement what you want to implement within your new branch

• Create a pull request from that branch to the deegree main branch

If the deegree main branch is changed during your implementation phase, it might be a good idea to merge these changes into your branch from time to time using git merge deegree/main. Make sure you've previously fetched the remote changes using git fetch --all.

Checklist for pull requests

Any pull request must meet the following base requirements, before it is considered for inclusion:

• Confirm you have read the contribution guidelines.
• There is an issue describing the bug/enhancement/feature.
• The description of the PR contains a link to the related issue and a short explanation what changes are included.
• It must be possible to merge the pull request automatically. You can check this yourself by opening the PR in GitHub.
• It must compile without errors and must not break any existing unit or integration tests. Here's a description for checking this yourself. Check the CI Jobs running on our Jenkins CI for errors.
• New features that add configuration files or options need to include corresponding documentation updates for the handbook.
• A pull request for the current version branch (current stable version) must come with a corresponding pull for main branch (current unstable version), or otherwise guarantee that the bugfix/improvement is not lost in the next version.
• The pull request contains changes related to a single objective. If multiple concerns cannot be avoided, each one is in its own commit and has a separate issue describing it.
• New unit tests have been added covering the changes you made.

Pull requests stuck workflow

On the rare occasion the TMC decides on not merging a PR into the deegree code base, and a pull request may be closed without being merged. The TMC tries to support every committer to pass the checklist as described above. In case a PR remains open and inactive for approx. 90 days, this PR will be marked as "stuck".
If no improvement has taken place to overcome the stuck state after an additional time frame of approx. 90 days, the TMC will automatically close the PR.

Lifecycle of a Pull request

• Open: Waiting for approval by the TMC.
• Stuck: The PR went inactive as there are open tasks like missing feedback or the PR was abandoned.
• Closed: After being automatically closed, a label "auto-closed" will be added to the PR.

Please keep in mind: No work will get lost. The code changes are still available, and a closed pull request can be reopened.