Difference between revisions of "Project policy"
SamHartman (talk | contribs) (Initial text) |
SamHartman (talk | contribs) m (→When are projects needed?) |
||
Line 9: | Line 9: | ||
The following always require the project process to be invoked: |
The following always require the project process to be invoked: |
||
− | # Introduction of any public [API]s |
+ | # Introduction of any public [[API]]s |
# Changes in an API or the [[ABI]]. Such changes are rarely approved |
# Changes in an API or the [[ABI]]. Such changes are rarely approved |
||
# Significant user interface changes such as the introduction of a new dialogue . |
# Significant user interface changes such as the introduction of a new dialogue . |
Revision as of 12:18, 19 November 2007
This page represents an official policy of the MIT Kerberos project. Edit this page only in accordance with changes agreed by the community; other changes will be reverted.
The Project Policy describes how members of the community propose to make changes in MIT Kerberos. A project is a proposal to add new functionality or to change existing functionality in MIT Kerberos. Projects are reviewed by the community before the required changes can be integrated into MIT Kerberos. This review provides the community an opportunity to suggest improvements to the project and to confirm that the community believes that implementing the project would be a good idea.
When are projects needed?
Small changes and relatively simple bug fixes do not require a project. The project process is designed to provide sufficient community review. If a change is simple enough and uncontroversial enough then the change can be made without going through this process. If members of the development community,especially members of Krbcore, wish to review the change then it should go through a project process. If a change is committed outside of a project and objections are raised, then any member of Krbcore may revert the change until a project is approved.
The following always require the project process to be invoked:
- Introduction of any public APIs
- Changes in an API or the ABI. Such changes are rarely approved
- Significant user interface changes such as the introduction of a new dialogue .
- Introduction of configuration file variables