Op Wednesday 11 March 2009 20:34 schreef u:
> On Monday 09 March 2009, Alexander Neundorf wrote:
> > Hi,
> > 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
> > kdelibs/cmake/modules/.
> > 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
> > 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 ?
> > Please let me know what you think about this.
> ...I should have put a "RFC" in the subject.
> Well, if there are no comments until next week Friday, March 20th, this will
> become the official commit policy for kdelibs/cmake/modules/.
> So if you have any suggestions, concerns, etc., let us know.
Looks ok to me.
Btw. please also consider KOffice and Extragear applications in the review
process. They can either depend on trunk or the latest branch, so a patch that
is committed in KDE's trunk can potentially break stuff for them.