commit policy for kdelibs/cmake/modules/

Alexander Neundorf neundorf at
Mon Mar 9 21:20:03 GMT 2009


the cmake files in kdelibs/cmake/modules/ are a core part of the buildsystem 
of KDE4 and they are also installed, so they are part of the source interface 
of KDE. To make sure we can guarantee some kind of quality for them, we agree 
on the kde-buildsystem list that we need a commit policy for 

So the files located there 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 compatibility. Committing there also has the potential to break the 
build of whole KDE for everybody.

Here is the proposal for a commit policy for kdelibs/cmake/modules/ :

1) Adding new files: new files must be sent to <the mailinglist>. They may 
only be added after an explicit ok. 
<the mailinglist> should be kde-buildsystem and/or kde-core-devel, not sure.

2) 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.
[this is quite unclear. What I have in mind is e.g. the patch which changed a 
bunch of modules to use pkg-config exclusively and by this broke them for all 
other cases)

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.

4) Documentation must never be removed as long as it is valid and not 

5) Other patches can always be committed.

6) All patches must comply the cmake guide on
[have to add something about pkg-config there]

Do we have to define who can give an ok ? Should we define a group of 
maintainers ?

Please let me know what you think about this.


More information about the kde-core-devel mailing list