KDE review.
As per this page, these are the steps to enter KDE review:
- You can move your project in repo-metadata, see repo-metadata README or file a Sysadmin ticket asking for the move. *(How?)
- See the Sanity Checklist for some of the elements people will review.
- E-mail kde-core-devel and other relevant mailing lists with details of your project and what the expected destination is for the repo.
- Make fixes to issues people bring up or provide explanation why they are not (yet) fixed.
- Wait at least two weeks in kdereview.
- After two months in kdereview the repo should be moved back to playground or moved to unmaintained.
- See KDEReview page for current status of projects (feel free to help maintain this page and push reviews forwards).
We need to send the corresponding emails and ensure the repos comply with the following checklist:
KDE Review checklist
-
If from outwith KDE, have completed Incubator -
The REUSE Specification - Version 3.0 shall be applied when stating licenses and when adding license files to a project. Each source file either must contain SPDX identifiers or licence headers to state under which terms the software may be used, modified and redistributed. See Licensing Policy -
Passing CI job for Reuse linting -
A Messages.sh file which extracts all the i18n() translations -
A metainfo.xml file (previously appdata.xml) with AppStream data AppStream Guidelines -
A screenshot in product-screenshots -
Check the code with some sanity tools like clazy or clang-tidy, if not already done as part of CI runs. -
Documentation appropriate to the project: API documentation, user documentation (including docbook or other format documented by the Documentation team) -
A bugs.kde.org product -
Passing Gitlab CI build jobs -
Passing KDE neon build -
App packages in Flatpak, Snap, AppImages and Windows etc as appropriate
Edited by Jonathan Riddell