Talk:Get Involved/Issue Reporting

From KDE Community Wiki

Bugzilla vs gitlab

As someone that has been following KDE development over the years superficially, it is unclear to me whether or not bugs can also be reported to KDE's gitlab instance at invent.kde.org as issues rather than creating tickets in bugzilla at bugs.kde.org?

According to information on this site, which is well exposed on www.kde.org, everything should go to bugs.kde.org as invent.kde.org is not even mentioned in this part of Get Involved. This brings me into confusion as there indeed are many issues tagged as bugs on gitlab.

What is the distinction? Perhaps, that issues on gitlab should be used mainly for components still in the development process (i.e. unreleased code in devel branch) and bug reports on bugzilla primarily for bugs for standard releases? Where should feature enhancement requests and wishes go?

Best, --Smihael (talk) 14:21, 26 November 2021 (UTC)


Some apps are already using GitLab issue against the generally recommended policy. They do this because GitLab issues works well for them, because they represent the standard intended use case of GitLab Issues as a bug reporting tool: a 1:1 mapping of git repo to software, with developers who (mostly) do basic bug triage for their own apps.

However this does not represent the reality for other KDE projects, such as Frameworks, Plasma, KWin, and System Settings. For products like these, GitLab issues works much less well and suffers from many significant issues, which currently block adoption.

It is unfortunate that we now have effectively two bug trackers and some small new apps using GitLab issues instead of Bugzilla. However it is what it is. In the meantime people are encouraged to report bugs to Bugzilla unless there is no Bugzilla component. In that case they can use GitLab issues.

- Nate

Thank you. For further reference, Nate has prepared an extensive wiki page with explanations which features are blocking usage of Gitlab for bug tracking. --Smihael (talk) 11:00, 1 January 2022 (UTC)

Instructions unclear upon finding existing ticket

The instructions currently say:

Look through the Bugzilla tickets that show up in the search results. If you find one that matches, great! Please do not intentionally open a duplicate Bugzilla ticket.

It's not clear what "great!" means.

  • ...Should the user in some way "upvote" the issue to add visibility?
  • ...Is it appropriate to comment, "I'm also experiencing this"?
  • ...Should the user attempt describe their similar use case if they believe it's different from the one in the initial ticket?
  • ...Should the user replicate the template ("Steps to reproduce", "Expected result", down to "Software/OS Versions"), or just include whatever data seems relevant to them.

Further, I was a little unclear on additional etiquette questions within the KDE Bugtracker. If a maintainer responds to my ticket and says they've replicated the issue, is it appropriate (or inappropriate or neither) to reply and say something like, "Thanks! Let me know if there's anything I can do," or something along those lines? Or does this waste people's time?

I'll happily edit the Wiki appropriately, I just don't know the answers to these questions. :(


I tweaked the wording a bit; feel free to tweak it some more.

In general every change made to a bugzilla ticket (including adding comments or keywords, changing the version number, and even CCing yourself) sends an email to everyone already subscribed to it. So it's best to only do this when you feel you have something that adds information not already present.

- Nate

Retrieved from "https://community.kde.org/index.php?title=Talk:Get_Involved/Issue_Reporting&oldid=100836"