Working with pull requests

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 marked for deletion

On the rare occasion the TMC decides on not merging a PR into the deegree code base 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 the PR remains open for approx. 12 months and no substantial improvement has taken place to overcome the requested approvements the TMC will mark a pull request with the label "marked for deletion". After an additional time frame of approx. 1 month the TMC will close 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.

Lifecycle of a Pull request

• Open: Waiting for approval by the TMC
• "Stuck": TMC has asked for improvements but got no feedback from the developer.
• "Marked for Deletion": The PR was "Stuck" for approx. 12 months without any activity
• Closed: After label "marked for deletion" was set and an additional month of inactivity the PR will be closed without being merged.