Frameworks/Policies

The strategy and policies for the KDE Frameworks effort is yet to be discussed and decided.

http://thread.gmane.org/gmane.comp.kde.devel.frameworks/37

This page is a starting point for further expansion.

Policies

Frameworks have a Tier and a Type

Each framework has a clear position in the Tier/Type matrix, its position forces a set of rules on its possible dependencies. This matrix and its rules are summarized in the Frameworks matrix document.

Framework directory structure

All the frameworks will have the same directory structure which will follow some rules:

The containing directory has the name of the technology (plasma, kio, itemmodels, etc.);
At the top level we find the common files like README, TODO, MAINTAINER, etc.
More comprehensive documentation go into a docs subdirectory
The source code for the targets go into src subdirectory, if several payload are built (like a core lib and a gui layer on top) then src will contain one subdirectory per library: core, gui, widgets, etc.
Code examples go into an examples subdirectory
Automatic tests go into an autotests subdirectory
Test applications go into a tests subdirectory

Frameworks have automatic unit tests

Enough said really... They must be unit tested with automatic unit tests.

Corollary: When fixing a but in a framework, the auto-test proving the bug and the fix should come in the same commit

Frameworks maintain binary compatibility

Just like we did in kdelibs, KDE Frameworks maintain the binary compatibility through their life time, for more details see [binary compatibility policy on techbase].

Note however that this policy is lifted during major version transition, corresponding epics of milestones will be marked as such.

Frameworks commits are reviewed

Make sure all commits in the master branch of a repository part of the KDE Frameworks got a proper review. As such commits must contain either a "Reviewed by:" (for quick pastebin reviews) or a "REVIEW:" (for more formal reviewboard reviews).