commit policy for kdelibs/cmake/modules/
neundorf at kde.org
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
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 techbase.kde.org
[have to add something about pkg-config there]
Do we have to define who can give an ok ? Should we define a group of
Please let me know what you think about this.
More information about the kde-core-devel