commit policy for kdelibs/cmake/modules/

Alexander Neundorf neundorf at kde.org
Fri Jan 16 21:40:50 CET 2009


Hi,

so let's start a discussion on a commit policy for kdelibs/cmake/modules/. 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.

So, how do we proceed ?

If something needs approvement, where should it be ?
Personally I would prefer kde-buildsystem, this would make it easier at least 
for me. But not everybody is subscribed here, so maybe better k-c-d ?
Or any of the two ?

1) Adding new files: new files must be sent to <the mailinglist>. They may 
only be added after an explicit ok.

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 function: 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 
replaced.

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 
maintainers ?

Alex


More information about the Kde-buildsystem mailing list