Skip to end of metadata
Go to start of metadata


Contribution Process

  • Provide a pull-request (PR) by forking the GDP repository on GitHub and opening a pull request.
  • You must follow Rules for Commit Messages
  • If for some reason you do not use GitHub, just negotiate another way of contributing with the maintainers (e.g. publish your fork somewhere else)
  • If it's a major change, some communication beforehand doesn't hurt.  (See JIRA tickets, and of course email).  A PR is basically seen a request to merge this now, rather than a long-term development location (not always possible, but as a principle).   Long term development is instead preferred to happen on your own branch/fork, or on an official feature branch of the GENIVI git repository.  We may ask to close a PR and reopen at a later time if a feature is not ready to merge. Talk to the maintainers and we will figure it out together.

    (warning) WARNING: The source branch of a PR can be updated by the GDP maintainers, and frequently will be (GitHub feature).  Therefore, if you provide a PR from your master branch, maintainers can, and will, force-push updates into it.  (See rebase and updating).   If you don't want your master branch to be modified, make sure a separate branch is set up as the source of the PR.

JIRA tickets

Rebasing and updating PRs

  • We generally prefer a linear history and will attempt to rebase new commits onto the tip of master (or feature branch where applicable).
  • When multiple PRs are open, they need to be merged in some order.  There is no fair way of doing this - any PR that is merged later than another PR will need a rebase.  If many PRs are open and merged, this can mean multiple rebasing before merging.
  • Sometimes rebasing can be done automatically during the merge, either through GitHub web interface or by the committer/maintainer, but we will also often ask the submitter to rebase and update the PR.  Please accept this as simply part of the process.
  • The reason for rebasing and updating the PR before merging is that the CI system will do a build check for each update.  Such a check is most valuable if it can ensure that nothing breaks when the change is placed on top of the latest master.
  • Rewriting the chain of commits could also be done to split/squash or add a new commit among the ones provided by the PR.
  • Updating the PR can be done at any time by either the PR submitter, or by a committer/maintainer and force-pushed to the PR source branch. (See (warning) WARNING).
  • Make sure to always make a comment in the PR when pushing changes to the PR.
  • NOTE: Amended patches or any other history rewrite shall also be force-pushed to the source branch of the PR, even if they are created during the merge process.  This is to ensure that GitHub will recognize the PR as merged despite that the patches changed.
  • Important guidelines for maintainers/committers with regards to when to update a PR, vs. request an update from the submitter, are on the Rules for Commit Messages page.

 

  • No labels