(list 'kdelibs coding style' + linkify api dox howto) |
(SVN Guidelines) |
||
| Line 7: | Line 7: | ||
;[[/SVN Commit Policy|SVN Commit Policy]] | ;[[/SVN Commit Policy|SVN Commit Policy]] | ||
:Rules for commits to the KDE SVN repository. The three golden rules (make sure it compiles, follow existing coding style, use descriptive log messages) and 18 more rules to follow to make sure that your SVN commits are the best they can be. | :Rules for commits to the KDE SVN repository. The three golden rules (make sure it compiles, follow existing coding style, use descriptive log messages) and 18 more rules to follow to make sure that your SVN commits are the best they can be. | ||
| + | |||
| + | ;[[/SVN Guidelines|SVN Guidelines]] | ||
| + | :Learn all about the Life Cycle of a KDE Application. Where you can upload new application, how to get in one of the main KDE modules and what to do when you give up maintainership of your application. | ||
;[[/Licensing Policy|Licensing Policy]] | ;[[/Licensing Policy|Licensing Policy]] | ||
There are a couple of written and unwritten rules KDE developers usually adhere to. The following documents summarize some of these policies. The list is still incomplete. If you are interested in helping out with formulating the KDE policies or would like to discuss them please use the kde-policies mailing list which was created for this purpose.
These policies apply to KDE developers and it is expected that all persons with a KDE SVN account follow these policies. The SVN commit policy is the most important one. Persons working on libraries (kdelibs mostly, but central libraries in other SVN modules fall under this as well) should read the library documentation policy (and the apidox howto as well).
Whereas policies are normative for individual developers -- that is, they describe how developers must behave -- procedures describe how 'the KDE project' as a whole has chosen to behave. We describe what we will do under certain circumstances and why.