Skip to content

Working with pull requests

Jump to bottom
tfr42 edited this page Feb 12, 2019 · 40 revisions

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 add remote deegree git://github.com/deegree/deegree3.git for the deegree3 repository

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

    • git checkout deegree/master
    • 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 master

If the deegree master 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/master. 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:

  • It must be possible to merge it automatically.
  • It must compile without errors and must not break any existing unit or integration tests. Here's a description for checking this yourself.
  • New features that add configuration files / options need to include corresponding documentation updates for the webservices handbook.
  • A pull request for the current version branch (current stable version) must come with a corresponding pull for master branch (current unstable version), or otherwise guarantee that the bugfix/improvement is not lost in the next version.

Pull requests marked for deletion

On the rare occaison 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 you can easily reopen every closed pull request.

Lifecycle of on 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.
Clone this wiki locally