Difference between revisions of "Contributing code"
| (9 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
| ⚫ | The MIT krb5 team is willing to accept code contributions in a variety of forms, but the most preferred method is a pull request for https://github.com/krb5/krb5 |
||
| + | This page describes guidelines for developers outside of the core MIT krb5 team. Developers with commit access should also read [[Committer resources]]. |
||
| + | |||
| ⚫ | The MIT krb5 team is willing to accept code contributions in a variety of forms, but the most preferred method is a pull request for https://github.com/krb5/krb5. Please follow the [[coding style]] guidelines, including the version control practices, and use the [[Coding style/Style checker|style checker]] script to help minimize style issues. Changes must be made against the master branch, not a release branch. |
||
| + | |||
| + | By default, we will commit code contributions using your name and email address in the git "author" metadata field and a committer's name and email in the git "committer" metadata field. If we make changes to the contribution when committing it, we will note that in square brackets in the commit message. If you prefer otherwise, let us know. |
||
For larger contributions such as new features, we have some additional requirements: |
For larger contributions such as new features, we have some additional requirements: |
||
| − | * The code must be available under a permissive license such as the |
+ | * The code must be available under a permissive license such as the 2-clause BSD license used for the project itself. We encourage, but do not require, copyright to be assigned to MIT to avoid adding to the number of licenses in our notice file. (All we need to consider copyright assigned is an unambiguous statement in email.) |
* There should be a [[Project policy|project proposal]] with a description of the use case and design of the change. |
* There should be a [[Project policy|project proposal]] with a description of the use case and design of the change. |
||
* There should be an opportunity for community feedback on the krbdev@mit.edu mailing list. |
* There should be an opportunity for community feedback on the krbdev@mit.edu mailing list. |
||
* There must be a way to test the new functionality. Automated test cases integrated with "make check" are required unless that would be unusually difficult due to the nature of the change. |
* There must be a way to test the new functionality. Automated test cases integrated with "make check" are required unless that would be unusually difficult due to the nature of the change. |
||
| − | * There should be documentation of the new functionality ( |
+ | * There should be documentation of the new functionality (in the RST sources in the "doc" directory of the source tree). |
In some cases we may be willing to fulfill these requirements ourselves, but that will postpone the acceptance of the contribution until we have the resources to do so. We also require a careful code review of any new code contribution by a core team member, and may have changes to request or may make changes ourselves. |
In some cases we may be willing to fulfill these requirements ourselves, but that will postpone the acceptance of the contribution until we have the resources to do so. We also require a careful code review of any new code contribution by a core team member, and may have changes to request or may make changes ourselves. |
||
| + | |||
| + | == Maintaining a github fork == |
||
| + | |||
| + | * [[Maintaining a github fork]] |
||
Latest revision as of 13:45, 4 March 2014
This page describes guidelines for developers outside of the core MIT krb5 team. Developers with commit access should also read Committer resources.
The MIT krb5 team is willing to accept code contributions in a variety of forms, but the most preferred method is a pull request for https://github.com/krb5/krb5. Please follow the coding style guidelines, including the version control practices, and use the style checker script to help minimize style issues. Changes must be made against the master branch, not a release branch.
By default, we will commit code contributions using your name and email address in the git "author" metadata field and a committer's name and email in the git "committer" metadata field. If we make changes to the contribution when committing it, we will note that in square brackets in the commit message. If you prefer otherwise, let us know.
For larger contributions such as new features, we have some additional requirements:
- The code must be available under a permissive license such as the 2-clause BSD license used for the project itself. We encourage, but do not require, copyright to be assigned to MIT to avoid adding to the number of licenses in our notice file. (All we need to consider copyright assigned is an unambiguous statement in email.)
- There should be a project proposal with a description of the use case and design of the change.
- There should be an opportunity for community feedback on the krbdev@mit.edu mailing list.
- There must be a way to test the new functionality. Automated test cases integrated with "make check" are required unless that would be unusually difficult due to the nature of the change.
- There should be documentation of the new functionality (in the RST sources in the "doc" directory of the source tree).
In some cases we may be willing to fulfill these requirements ourselves, but that will postpone the acceptance of the contribution until we have the resources to do so. We also require a careful code review of any new code contribution by a core team member, and may have changes to request or may make changes ourselves.
