Difference between revisions of "Contributing to MPICH"

From Mpich
Jump to: navigation, search
Line 5: Line 5:
 
* [https://help.github.com/articles/proposing-changes-to-your-work-with-pull-requests Proposing changes to your work with pull requests]
 
* [https://help.github.com/articles/proposing-changes-to-your-work-with-pull-requests Proposing changes to your work with pull requests]
 
** [https://help.github.com/articles/creating-a-pull-request-from-a-fork Creating a pull request from a fork]
 
** [https://help.github.com/articles/creating-a-pull-request-from-a-fork Creating a pull request from a fork]
 +
 +
Some things to remember when creating a patchset.
 +
* Describe your changes, both in the pull request description and in each individual commit message.
 +
** Describe the underlying issue, whether it be a bug or a new feature.
 +
** Describe the user-visible impact it will have.
 +
* Separate your changes so that there is one logical change per patch.
 +
** Each patch should stand on its own merits. If a patch depends on a previous one, it is helpful to note that in the commit message.
 +
** Each patch in a series should be able to compile and run. This way bugs can be traced down using <code>git bisect</code> in the future.
 +
** [https://chris.beams.io/posts/git-commit/ How to Write a Git Commit Message]

Revision as of 15:56, 17 May 2017

For a person or company who wishes to submit a change to MPICH, you must first submit a signed contributors' agreement. http://www.mpich.org/documentation/contributor-docs/

MPICH uses git to manage source code. The official repository is located at https://github.com/pmodels/mpich. Changes should be submitted in the form of a "pull request". More info on pull requests can be found here: https://help.github.com/categories/collaborating-with-issues-and-pull-requests/. Some of the more relevant sections for outside collaborators are:

Some things to remember when creating a patchset.

  • Describe your changes, both in the pull request description and in each individual commit message.
    • Describe the underlying issue, whether it be a bug or a new feature.
    • Describe the user-visible impact it will have.
  • Separate your changes so that there is one logical change per patch.
    • Each patch should stand on its own merits. If a patch depends on a previous one, it is helpful to note that in the commit message.
    • Each patch in a series should be able to compile and run. This way bugs can be traced down using git bisect in the future.
    • How to Write a Git Commit Message