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