Frameworks/Policies: Difference between revisions
Fixed link |
Remove top-level "Policies" heading; the page title is enough for that |
||
| Line 5: | Line 5: | ||
This page is a starting point for further expansion. | This page is a starting point for further expansion. | ||
== 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 [http://files.kde.org/sprints/platform11/kde-frameworks-matrix.pdf Frameworks matrix document]. | 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 [http://files.kde.org/sprints/platform11/kde-frameworks-matrix.pdf Frameworks matrix document]. | ||
| Line 23: | Line 20: | ||
* Solutions have a mandatory runtime dependencies, it is part of their design and where their added value comes from (think scalability, resource sharing, resilience, etc.). | * Solutions have a mandatory runtime dependencies, it is part of their design and where their added value comes from (think scalability, resource sharing, resilience, etc.). | ||
== Framework directory structure == | |||
All the frameworks will have the same directory structure which will follow some rules: | 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.); | * The containing directory has the name of the technology (plasma, kio, itemmodels, etc.); | ||
| Line 34: | Line 31: | ||
== Frameworks have automatic unit tests == | |||
Enough said really... They must be unit tested with automatic unit tests. | Enough said really... They must be unit tested with automatic unit tests. | ||
| Line 45: | Line 42: | ||
== 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). | 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). | ||
Revision as of 20:15, 4 December 2011
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.
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.
The constraints from Tiers are the following:
- Tier 1 Frameworks can depend only on Qt official frameworks or other system libraries;
- Tier 2 Frameworks can depend only on Tier 1 Frameworks, Qt official frameworks, or other system libraries;
- Tier 3 Frameworks can depend only on other Tier 3 Frameworks, Tier 2 Frameworks, Tier 1 Frameworks, Qt official frameworks, or other system libraries.
The constraints from Types are the following:
- Functional Qt Addons cannot have runtime dependencies;
- Integration Qt Addons can have an optional runtime dependencies and aim at integrating with the underlying OS/Platform;
- Solutions have a mandatory runtime dependencies, it is part of their design and where their added value comes from (think scalability, resource sharing, resilience, etc.).
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 [| the 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).