Policies/CMake Commit Policy: Difference between revisions

From KDE Community Wiki
(New page: The files located in kdelibs/cmake/modules/ are installed and can be used by other application. This means they are part of the public interface of kdelibs and we have to keep compatibil...)
 
m (7 revisions imported: Move Policies from techbase)
 
(6 intermediate revisions by 3 users not shown)
Line 1: Line 1:
The files located in kdelibs/cmake/modules/ are installed and can be used by other application.  
The policies outlined here apply to the CMake files in kdelibs/cmake/modules/, i.e. they don't apply to CMake files in other KDE modules.
This means they are part of the public interface of kdelibs and we have to  
keep compatibility. Committing there also has the potential to break the
build of whole KDE for everybody.


When committing changes thereHere is the proposal for a commit policy for kdelibs/cmake/modules/ :
The files located in kdelibs/cmake/modules/ are installed and can be used by other applications. This means they are part of the public interface of kdelibs and we have to keep compatibility. Committing there also has the potential to break the build of whole KDE for everybody.


# Adding new files: new files must be sent to [email protected] for review. They may only be added after an explicit ok.  
When committing changes in kdelibs/cmake/modules/, the following rules must be followed:
# Patches which change how something is done in general for many files must be posted first. They may only be committed after an explicit ok.
 
# Adding public macros or functions: they must be posted for review first. If there is NO answer at all within two weeks they may be committed anyway.
# '''Adding new files''': new files must be sent to [email protected] for review. They may only be added after an explicit Ok.  
# Patches which '''refactor multiple modules''' at once or which change how something is done in general for multiple files must be posted first. They may only be committed after an explicit Ok.
# '''Adding public macros or functions''': they must be posted for review first. If there is NO answer at all within two weeks they may be committed anyway.
# Documentation must never be removed as long as it is valid and not replaced.
# Documentation must never be removed as long as it is valid and not replaced.
# Other patches can always be committed.
# Other patches can always be committed without review.
# All patches must maintain source compatibility.
# All patches must maintain [[Policies/CMake and Source Compatibility|source compatibility]].
# All patches must follow the [[Policies/CMake Coding Style|coding style]] for CMake files in KDE.

Latest revision as of 16:12, 8 March 2016

The policies outlined here apply to the CMake files in kdelibs/cmake/modules/, i.e. they don't apply to CMake files in other KDE modules.

The files located in kdelibs/cmake/modules/ are installed and can be used by other applications. This means they are part of the public interface of kdelibs and we have to keep compatibility. Committing there also has the potential to break the build of whole KDE for everybody.

When committing changes in kdelibs/cmake/modules/, the following rules must be followed:

  1. Adding new files: new files must be sent to [email protected] for review. They may only be added after an explicit Ok.
  2. Patches which refactor multiple modules at once or which change how something is done in general for multiple files must be posted first. They may only be committed after an explicit Ok.
  3. Adding public macros or functions: they must be posted for review first. If there is NO answer at all within two weeks they may be committed anyway.
  4. Documentation must never be removed as long as it is valid and not replaced.
  5. Other patches can always be committed without review.
  6. All patches must maintain source compatibility.
  7. All patches must follow the coding style for CMake files in KDE.