Policies: Difference between revisions
No edit summary |
(Marked this version for translation) |
||
| Line 2: | Line 2: | ||
<translate> | <translate> | ||
== Introduction to Policies == | == Introduction to Policies == <!--T:1--> | ||
<!--T:2--> | |||
There are a couple of written and unwritten rules KDE developers usually adhere to. The following documents summarize some of these policies. The list is still incomplete. If you are interested in helping out with formulating the KDE policies or would like to discuss them please use the [https://mail.kde.org/mailman/listinfo/kde-policies kde-policies mailing list] which was created for this purpose. | There are a couple of written and unwritten rules KDE developers usually adhere to. The following documents summarize some of these policies. The list is still incomplete. If you are interested in helping out with formulating the KDE policies or would like to discuss them please use the [https://mail.kde.org/mailman/listinfo/kde-policies kde-policies mailing list] which was created for this purpose. | ||
== Policies for Developers == | == Policies for Developers == <!--T:3--> | ||
<!--T:4--> | |||
These policies apply to KDE developers and it is expected that all persons with a KDE SVN account follow these policies. The SVN commit policy is the most important one. Persons working on libraries (kdelibs mostly, but central libraries in other SVN modules fall under this as well) should read the library documentation policy (and the apidox howto as well). | These policies apply to KDE developers and it is expected that all persons with a KDE SVN account follow these policies. The SVN commit policy is the most important one. Persons working on libraries (kdelibs mostly, but central libraries in other SVN modules fall under this as well) should read the library documentation policy (and the apidox howto as well). | ||
<!--T:5--> | |||
;[[/SVN Commit Policy|SVN Commit Policy]] | ;[[/SVN Commit Policy|SVN Commit Policy]] | ||
:Rules for commits to the KDE SVN repository. The three golden rules (make sure it compiles, follow existing coding style, use descriptive log messages) and 18 more rules to follow to make sure that your SVN commits are the best they can be. | :Rules for commits to the KDE SVN repository. The three golden rules (make sure it compiles, follow existing coding style, use descriptive log messages) and 18 more rules to follow to make sure that your SVN commits are the best they can be. | ||
<!--T:6--> | |||
;[[/SVN Guidelines|Application Life Cycle]] | ;[[/SVN Guidelines|Application Life Cycle]] | ||
:Learn all about the Life Cycle of a KDE Application. Where you can upload new application, how to get in one of the main KDE modules and what to do when you give up maintainership of your application. | :Learn all about the Life Cycle of a KDE Application. Where you can upload new application, how to get in one of the main KDE modules and what to do when you give up maintainership of your application. | ||
<!--T:7--> | |||
;[[/Licensing Policy|Licensing Policy]] | ;[[/Licensing Policy|Licensing Policy]] | ||
:Files in KDE SVN cannot be arbitrarily licensed. This policy explains what licenses are allowed where in the repository. In short: use LGPL for libraries, GPL or BSD for everything else. | :Files in KDE SVN cannot be arbitrarily licensed. This policy explains what licenses are allowed where in the repository. In short: use LGPL for libraries, GPL or BSD for everything else. | ||
<!--T:8--> | |||
;[[/Library Documentation Policy|Library Documentation Policy]] | ;[[/Library Documentation Policy|Library Documentation Policy]] | ||
:Libraries for (re)use should be completely documented. This policy explains why as well as how to document things, and what style to follow. The [[Development/Tutorials/API Documentation|apidox howto]] contains more technical information on writing documentation for libraries. | :Libraries for (re)use should be completely documented. This policy explains why as well as how to document things, and what style to follow. The [[Development/Tutorials/API Documentation|apidox howto]] contains more technical information on writing documentation for libraries. | ||
<!--T:9--> | |||
;[[/Library Code Policy|Library Code Policy]] | ;[[/Library Code Policy|Library Code Policy]] | ||
:KDE Library API and Code should follow some conventions that are explained in this policy. | :KDE Library API and Code should follow some conventions that are explained in this policy. | ||
<!--T:10--> | |||
;[[/Kdelibs Coding Style|Kdelibs Coding Style]] | ;[[/Kdelibs Coding Style|Kdelibs Coding Style]] | ||
:This document describes the recommended coding style for kdelibs. Nobody is forced to use this style, but to have consistent formating of the source code files it is recommended to make use of it. | :This document describes the recommended coding style for kdelibs. Nobody is forced to use this style, but to have consistent formating of the source code files it is recommended to make use of it. | ||
<!--T:11--> | |||
;[[/Kdepim Coding Style|Kdepim Coding Style]] | ;[[/Kdepim Coding Style|Kdepim Coding Style]] | ||
:This document describes the recommended coding style for kdepim. Nobody is forced to use this style, but to have consistent formating of the source code files it is strengly recommended to make use of it. | :This document describes the recommended coding style for kdepim. Nobody is forced to use this style, but to have consistent formating of the source code files it is strengly recommended to make use of it. | ||
<!--T:12--> | |||
;[[/New_KDE_Library_API_Policy|Adding New Classes to kdelibs]] | ;[[/New_KDE_Library_API_Policy|Adding New Classes to kdelibs]] | ||
:Recommendations on how to add new classes or libraries to kdelibs. | :Recommendations on how to add new classes or libraries to kdelibs. | ||
<!--T:13--> | |||
;[[/CMake Coding Style|CMake Coding Style]] | ;[[/CMake Coding Style|CMake Coding Style]] | ||
:This document describes the recommended coding style for CMake files in KDE. | :This document describes the recommended coding style for CMake files in KDE. | ||
<!--T:14--> | |||
;[[/CMake and Source Compatibility|CMake and Source Compatibility]] | ;[[/CMake and Source Compatibility|CMake and Source Compatibility]] | ||
:Keeping future KDE releases CMake-compatible. | :Keeping future KDE releases CMake-compatible. | ||
<!--T:15--> | |||
;[[/CMake Commit Policy|CMake Commit Policies]] | ;[[/CMake Commit Policy|CMake Commit Policies]] | ||
:Rules to follow when considering a change to the CMake buildsystem. | :Rules to follow when considering a change to the CMake buildsystem. | ||
<!--T:16--> | |||
;[[/Binary Compatibility Issues With C++|Binary Compatibility Issues With C++]] ([http://developer.kde.org/documentation/other/binarycompatibility.html Original]) | ;[[/Binary Compatibility Issues With C++|Binary Compatibility Issues With C++]] ([http://developer.kde.org/documentation/other/binarycompatibility.html Original]) | ||
:A quick overview of issues with binary compatibility with C++. Keep this in mind while altering the API of kdelibs. | :A quick overview of issues with binary compatibility with C++. Keep this in mind while altering the API of kdelibs. | ||
<!--T:17--> | |||
;[[/URI & XML Namespaces Policy|URI & XML Namespaces Policy]] | ;[[/URI & XML Namespaces Policy|URI & XML Namespaces Policy]] | ||
:Sometimes KDE technologies and applications needs URIs, such as for XML formats. This policy describes practices for that, and how to allocate URIs. | :Sometimes KDE technologies and applications needs URIs, such as for XML formats. This policy describes practices for that, and how to allocate URIs. | ||
<!--T:18--> | |||
;[[/API to Avoid|API to Avoid]] | ;[[/API to Avoid|API to Avoid]] | ||
:There are classes and functions in Qt or other places that should be avoided by KDE applications. | :There are classes and functions in Qt or other places that should be avoided by KDE applications. | ||
== Procedures == | == Procedures == <!--T:19--> | ||
<!--T:20--> | |||
Whereas policies are normative for individual developers -- that is, they describe how developers must behave -- procedures describe how 'the KDE project' as a whole has chosen to behave. We describe what we will do under certain circumstances and why. | Whereas policies are normative for individual developers -- that is, they describe how developers must behave -- procedures describe how 'the KDE project' as a whole has chosen to behave. We describe what we will do under certain circumstances and why. | ||
<!--T:21--> | |||
;[[/Security Policy|Security Policy]] | ;[[/Security Policy|Security Policy]] | ||
:How security problems can be reported to [mailto:[email protected] [email protected]] and how the security team responds to security issues. | :How security problems can be reported to [mailto:[email protected] [email protected]] and how the security team responds to security issues. | ||
<!--T:22--> | |||
;[[/Packaging Policy|Packaging Policy]] | ;[[/Packaging Policy|Packaging Policy]] | ||
:This describes KDE's viewpoint on binary packages and elaborates the statement 'KDE provides source.' | :This describes KDE's viewpoint on binary packages and elaborates the statement 'KDE provides source.' | ||
<!--T:23--> | |||
;[[/Minor_Point_Release_Policy|Point Release Policy]] | ;[[/Minor_Point_Release_Policy|Point Release Policy]] | ||
:Discusses KDE policies for minor point releases. | :Discusses KDE policies for minor point releases. | ||
<!--T:24--> | |||
[[Category:Policies]] | [[Category:Policies]] | ||
</translate> | </translate> | ||
Revision as of 15:09, 6 March 2013
Introduction to Policies
There are a couple of written and unwritten rules KDE developers usually adhere to. The following documents summarize some of these policies. The list is still incomplete. If you are interested in helping out with formulating the KDE policies or would like to discuss them please use the kde-policies mailing list which was created for this purpose.
Policies for Developers
These policies apply to KDE developers and it is expected that all persons with a KDE SVN account follow these policies. The SVN commit policy is the most important one. Persons working on libraries (kdelibs mostly, but central libraries in other SVN modules fall under this as well) should read the library documentation policy (and the apidox howto as well).
- SVN Commit Policy
- Rules for commits to the KDE SVN repository. The three golden rules (make sure it compiles, follow existing coding style, use descriptive log messages) and 18 more rules to follow to make sure that your SVN commits are the best they can be.
- Application Life Cycle
- Learn all about the Life Cycle of a KDE Application. Where you can upload new application, how to get in one of the main KDE modules and what to do when you give up maintainership of your application.
- Licensing Policy
- Files in KDE SVN cannot be arbitrarily licensed. This policy explains what licenses are allowed where in the repository. In short: use LGPL for libraries, GPL or BSD for everything else.
- Library Documentation Policy
- Libraries for (re)use should be completely documented. This policy explains why as well as how to document things, and what style to follow. The apidox howto contains more technical information on writing documentation for libraries.
- Library Code Policy
- KDE Library API and Code should follow some conventions that are explained in this policy.
- Kdelibs Coding Style
- This document describes the recommended coding style for kdelibs. Nobody is forced to use this style, but to have consistent formating of the source code files it is recommended to make use of it.
- Kdepim Coding Style
- This document describes the recommended coding style for kdepim. Nobody is forced to use this style, but to have consistent formating of the source code files it is strengly recommended to make use of it.
- Adding New Classes to kdelibs
- Recommendations on how to add new classes or libraries to kdelibs.
- CMake Coding Style
- This document describes the recommended coding style for CMake files in KDE.
- CMake and Source Compatibility
- Keeping future KDE releases CMake-compatible.
- CMake Commit Policies
- Rules to follow when considering a change to the CMake buildsystem.
- Binary Compatibility Issues With C++ (Original)
- A quick overview of issues with binary compatibility with C++. Keep this in mind while altering the API of kdelibs.
- URI & XML Namespaces Policy
- Sometimes KDE technologies and applications needs URIs, such as for XML formats. This policy describes practices for that, and how to allocate URIs.
- API to Avoid
- There are classes and functions in Qt or other places that should be avoided by KDE applications.
Procedures
Whereas policies are normative for individual developers -- that is, they describe how developers must behave -- procedures describe how 'the KDE project' as a whole has chosen to behave. We describe what we will do under certain circumstances and why.
- Security Policy
- How security problems can be reported to [email protected] and how the security team responds to security issues.
- Packaging Policy
- This describes KDE's viewpoint on binary packages and elaborates the statement 'KDE provides source.'
- Point Release Policy
- Discusses KDE policies for minor point releases.