Difference between revisions of "Contributing to MPICH"
From Mpich
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