Skip to content

Latest commit

 

History

History
103 lines (85 loc) · 4.68 KB

CONTRIBUTING.md

File metadata and controls

103 lines (85 loc) · 4.68 KB
Raw

Contributing to Disman

Logging and Debugging

The first step in contributing to the project by either providing meaningful feedback or by sending in patches is always the analysis of the runtime behavior of a program that makes use of Disman. This means studying the debug log of the program.

Runtime logging

KDisplay with its daemon module and KCM is a program that makes use of Disman. For further information on how to log and debug KDisplay and by that also Disman see the respective chapter Logging and Debugging in KDisplay's Contributing document.

Disman's D-Bus backend service

Disman is primarily a library that other programs like KDisplay can link against to make use of additional functionality.

But Disman also contains a second component that runs on its own: a D-Bus service that acts as a backend launcher. Under normal operation this service is always launched once per session when an arbitrary program that uses Disman is executed. By this the service provides a single shared backend connection for all programs that make use of Disman.

To view the log of the service you must find the location of the service binary file. This is normally found at some path like /usr/lib/libexec/disman-launcher and then you can simply kill and restart the service with the command:

killall -9 disman-launcher ; /usr/lib/libexec/disman-launcher

Note that afterwards you need to restart all programs that made use of the old instance of the service to be able to connect to the new one. When you start another program that makes use of Disman it will automatically connect to this new service instance.

Submission Guideline

Code contributions to Disman are very welcome but follow a strict process that is layed out in detail in Wrapland's Contributing document.

Summarizing the main points:

  • Use pull requests directly for smaller contributions, but create issue tickets beforehand for larger changes.
  • Adhere to the KDE Frameworks Coding Style.
  • Pull requests have to be posted against master or a feature branch. Commits to the stable branch are only cherry-picked from the master branch after some testing on the master branch.

Commit Message Guideline

The Conventional Commits 1.0.0 specification is applied with the following amendments:

  • Only the following types are allowed:
    • build: changes to the CMake build system, dependencies or other build-related tooling
    • ci: changes to CI configuration files and scripts
    • docs: documentation only changes to overall project or code
    • feat: new feature
    • fix: bug fix
    • perf: performance improvement
    • refactor: rewrite of code logic that neither fixes a bug nor adds a feature
    • style: improvements to code style without logic change
    • test: addition of a new test or correction of an existing one
  • Only the following optional scopes are allowed:
    • ctl
    • lib
    • qscreen
    • randr
    • wayland
  • Angular's Revert and Subject policies are applied.

Example

fix(lib): provide correct return value

For function exampleFunction the return value was incorrect.
Instead provide the correct value A by changing B to C.

Tooling

See Wrapland's documentation for available tooling.