this post was submitted on 20 Aug 2023
13 points (84.2% liked)

KDE

5246 readers
81 users here now

KDE is an international technology team creating user-friendly free and open source software for desktop and portable computing. KDE’s software runs on GNU/Linux, BSD and other operating systems, including Windows.

Plasma 6 Bugs

If you encounter a bug, proceed to https://bugs.kde.org, check whether it has been reported.

If it hasn't, report it yourself.

PLEASE THINK CAREFULLY BEFORE POSTING HERE.

Developers do not look for reports on social media, so they will not see it and all it does is clutter up the feed.

founded 1 year ago
MODERATORS
 

Currently KDE uses Gitlab at invent.kde.org. Gitlab has been known to not be entirely open. I wonder if KDE has considered moving over to Gitea/Forgejo/Codeberg instead? And if not, how come?

you are viewing a single comment's thread
view the rest of the comments
[–] 2xsaiko@discuss.tchncs.de 2 points 1 year ago (1 children)

I’m honestly not sure that a central database for bugs is the best of ideas. The issues for a project should, ideally, be tied to, and integrated with that specific project.

It’s very very useful when looking for bugs to at the very least have a central search, I’ve encountered issues before which are filed against a completely different app than the one I’m encountering it in (usually because the issue is actually in a library that both use), which I would have missed otherwise. Having a single database also allows then moving bugs between projects in cases such as that without having to recreate it and linking the old one to the new one.

Also in case you haven’t seen it yet, here are KDE’s official reasons for sticking to Bugzilla: https://community.kde.org/Get_Involved/Issue_Reporting/Why_not_GitLab_Issues

[–] Kalcifer@lemm.ee 1 points 1 year ago

It’s very very useful when looking for bugs to at the very least have a central search, I’ve encountered issues before which are filed against a completely different app than the one I’m encountering it in (usually because the issue is actually in a library that both use), which I would have missed otherwise. Having a single database also allows then moving bugs between projects in cases such as that without having to recreate it and linking the old one to the new one.

Perhaps a middle ground would be to organize individual repositories under an organization, like on github, where the organization has a global bug tracker, as well as each project.