Review Request for KWayland for inclusion in frameworks

Martin Graesslin mgraesslin at kde.org
Fri Apr 15 08:08:57 UTC 2016


Hi frameworks-developers,

based on the thread "KWayland as framework" [1] I want to start the review 
process for including KWayland into frameworks.

To make it easier I'm giving an overview:
Policies [2]:
* Tier 1/integration - dependencies on Qt::Gui (5.4) and Wayland (1.7)
* directory structure
 ** name of toplevel directory: kwayland
 ** README.md: check
 ** COPYING.LIB: check
 ** metadata.yaml: check
 ** docs subdirectory: no additional documentation
 ** src with dedicated subdirectories: check, there is src/client and src/
server
 ** examples subdirectory: no dedicated examples
 ** autotests subdirectory: check
 ** tests subdirectory: check
 ** cmake subdirectory: not needed
* automatic unit test: the current line coverage for client library is 86 %, 
the line coverage for server library is 80 %
* binary compatibility: KWayland has been ABI stable since it got added to 
Plasma
* documentation: yes, the API is documented
* localization: not needed, no user visible strings
* buildsystem:
  ** KF5WaylandConfig.cmake is generated
  ** KF5WaylandConfigVersion.cmake is generated
  ** no other cmake files are installed
  ** library names are camel case: KF5WaylandServer and KF5WaylandClient
  ** dependencies to other frameworks: it's tier 1, doesn't apply
* commits are reviewed: yes, but KWayland is already using phabricator
* CI failures are treated as stop the line events: I like my view green ;-)
* compiler requirements:
  ** gcc 4.5: I don't know, the minimum gcc version my distribution offers is 
4.7
  ** clang 3.1: I don't know, the minimum clang version my distribution offers 
is 3.5
 **  VS2012: doesn't apply, it's Linux only [5]
 ** constraints for other C++11 features: it compiles on build.kde.org, so 
should be fine

Guidelines [3]:
* Policies: see above
* translations: doesn't apply
* split repository: yes, all commits were extracted when creating the project
* astyle: the code follows the kdelibs coding style from the start, didn't run 
astyle again
* Dependencies on deprecated API: none
* module in frameworks: not yet, currently still in Plasma [4]
* kde-build-metadata: not yet, currently still in Plasma [4]
* CI Jobs: currently still for Plasma [4]: https://build.kde.org/job/kwayland
%20master%20kf5-qt5/
* bugs.kde.org project: currently still in Plasma [4]
* reviewboard: yes
* README.md: yes

If you have any further questions regarding the move, please ask. If I don't 
get any blocking feedback in the next two weeks, I'm going to request the move 
and hope to get it into next frameworks release if that works with David ;-)

Thanks,
Martin

[1] https://mail.kde.org/pipermail/kde-frameworks-devel/2016-March/032116.html
[2] https://community.kde.org/Frameworks/Policies
[3] https://community.kde.org/Frameworks/CreationGuidelines
[4] I'll do those tasks if we get the green light for move to frameworks, 
otherwise it'll stay in Plasma
[5] some code uses linux includes, to support other Unix-systems porting is 
needed
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20160415/c1989807/attachment.sig>


More information about the Plasma-devel mailing list