Software development process/workflow in KDE

Development
1

Hi. I would like to contribute to KDE. I am hoping to gain familiarity with the KDE software development process by starting solving easy bugs/junior jobs. I am considering in tackling this one:

https://bugs.kde.org/show_bug.cgi?id=408979

I know it will take me a while since I’m not familiar with Qt, so, maybe it’s too early but I was wondering what the process of getting a bug solved is.

I read the this page and it explains many things but I still have some questions. For instance:

  • I see in bugzilla that some bugs have the status “ASSIGNED”, but does anyone assign the bugs to a person? do you do it yourself? is it only for KDE developers?
  • The aforementioned page explains that you should fork a project and then commit your changes there. I was wondering how kde-builder/kdesrc-build help in the development process.
  • Are there unit tests or integration tests that should be written and checked before committing a change?
  • Are there other resources where someone explains their development workflow?
2

I see in bugzilla that some bugs have the status “ASSIGNED”, but does anyone assign the bugs to a person? do you do it yourself? is it only for KDE developers?

I think in normally it means someone already made a merge request (MR) to fix that bug (and the MR description contains “BUG: bug-id”), and it’s waiting for review.

The aforementioned page explains that you should fork a project and then commit your changes there. I was wondering how kde-builder/kdesrc-build help in the development process.

kde-builder helps you checkout and build a project and its dependencies. You do the fork on https://invent.kde.org/, and commit with git.

Are there unit tests or integration tests that should be written and checked before committing a change?

Depends on the project. But surely is nice to have.

3 Likes
3

Thanks for answering. I still struggle to grasp some parts of the development workflow.

Let’s say you want to fix a bug. The way I imagine it so far is as follows:

  1. Get source code and dependencies using kde-builder.
  2. Fork the same project and clone it to your machine in a directory other than ~/kde/src/<proj> (assuming that’s the place where kde-builder downloads the source code).
  3. Configure your IDE/environment so the local fork source code gets any dependencies from ~/kde/src/<proj> and do all the work in the local fork
  4. Push the changes from the local fork to your repository, then do a merge request.

With the steps above you’ll have the same source code twice. Can you work directly in the source code downloaded by kde-builder? How do you usually work?

5

Are you familiar with git? Set up your fork on invent.kde.org as a remote in the repo that kde-builder cloned.

More reading:

I think there is a default assignee for all products on bugs.kde.org. At least I don’t remember ever seeing a bug that wasn’t assigned to anyone.

6

It’s independent of the “ASSIGNED” state.

7

As others answered, add your fork as another remote in the directory kde-builder cloned: git remote add personal <your fork url>

Then when pushing a branch for the first time, push to your fork: git push --set-upstream personal <your branch>

8

Ah right, the original question was about the status field, not the assignee field. I need to read more carefully.

9

Alright, now it’s clearer. Thanks.