Frameworks/Epics/Splitting kdelibs: Difference between revisions

Revision as of 09:30, 3 December 2011

kdelibs splitting epic

Important Forewords

If you are working on splitting a framework, make sure to consult our list of common issues. It will give you an overview of the solutions you're supposed to use to deal with some of the dependencies.

Also, when splitting out a framework, it is part of being done to comply with the KDE Frameworks Policies, it will also need to follow this Epic Policies. Any framework in the staging area cannot move to its final place without following those policies.

And last but not least, if you create a new framework, please consider being its maintainer as well. We need people to ensure the stewardship of all the frameworks.

Existing frameworks

Definition of done:

No dependency on kdeui or kdecore
Modularized CMakeLists.txt
Follows the policy on directory organization
Unit tested
Has an appointed maintainer

Status	Framework	Tier	Type	Maintainer	Comment
DONE	itemmodels	Tier 1	Functional	Stephen Kelly
IN PROGRESS	libkauth	Tier 1	Integration	Dario Freddi	Not following directory organization yet Unit tests?
IN PROGRESS	libkdbusaddons	Tier1	Functional	Kevin Ottens	Not following directory organization yet Wrongly named libkdbus
IN PROGRESS	libkplotting	Tier 1	Functional	??	Maintainer missing
IN PROGRESS	solid	Tier 1	Integration	Alex Fiestas	Not following directory organization yet
IN PROGRESS	threadweaver	Tier 1	Functional	??	Not following directory organization yet Maintainer missing
IN PROGRESS	sonnet	Tier 2	Functional	??	Not following directory organization yet Maintainer missing
IN PROGRESS	libkarchive	Tier 1	Functional	Mario Bensi	Depends on KSaveFile Depends on KMimeType
IN PROGRESS	libkcoreaddon	Tier 1	Functional	??	Maintainer missing? Unit tests? Why is it still in staging?

Backlog

For reference, find the class by class analysis produced during Platform11 on the kdelibs dependencies page

This list is non-final, hence why it is not integrated in the table above, when the scope of a lib gets defined and worked on, it is removed from this list and go in the table above.

Yet to be produced frameworks (foreseen tier and type, not set in stone):

Tier 1
- kguiaddons (Tier 1 / Functional)
- idletime (Tier 1 / Integration)

Tier 2
- libkconfig (Tier 2 / Functional)
- libkconfiggui (Tier 2 / Functional)
- window management (Tier 2 / Integration)
- color widgets (Tier 2 / Functional)
- job widgets (Tier 2 / Functional)
- widgets (Tier 2 / Functional)

Tier 3
- libkservice (Tier 3 / Solution)
- libkdebug (Tier 3 / Functional)
- itemviews (Tier 3 / Functional)
- XMLGUI (Tier 3 / Functional)
- dialogs (Tier 3 / Functional)
- emoticons (Tier 3)

Unknown Tier
- kbookmarks
- kio-core
- kio-widgets
- plasma

Tier 4
- kcmutils (Tier4)
- kde consistency framework (Tier 4)
- kparts (Tier 4)
- kde4support (Tier 4)

And probably more...

@@ Line 5: / Line 5: @@
 If you are working on splitting a framework, make sure to consult [[Frameworks/Splitting_kdelibs/Common_Solutions|our list of common issues]]. It will give you an overview of the solutions you're supposed to use to deal with some of the dependencies.
-Also, when splitting out a framework, it is part of being done to comply with the [[Frameworks/Strategy_and_Policies|strategies and policies]]. Any framework in the staging area cannot move to its final place without following those policies.
+Also, when splitting out a framework, it is part of being done to comply with the [[Frameworks/Policies|KDE Frameworks Policies]], it will also need to follow this Epic Policies. Any framework in the staging area cannot move to its final place without following those policies.
 And last but not least, if you create a new framework, please consider being its maintainer as well. We need people to ensure the stewardship of all the frameworks.