Contributing code

From K5Wiki
Revision as of 14:45, 4 March 2014 by TomYu (talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

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.

Maintaining a github fork