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?
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?
I do like the more modular approach that they took – many services unfortunately go the route of trying to make an “everything app” which often leads to bloat. This is of course not to accuse Gitea, Gitlab, Github, etc. of bloat, I’m just saying, in general, I do understand why they took this approach, and I can certainly appreciate it. I will say that, compared to the usual git services (Gitlab, Github, Gitea, etc.) it is severely lacking polish.
I personally despise bugzilla. It’s one of my least favorite parts about contributing to KDE. I personally find it very unintuitive, and messy. The UX of the service, on the whole, is not a pleasure.
I wouldn’t necessarily say that, it does work well for a lot of projects when used as an all in one package to have all development on, especially when it’s a public instance for many different projects such as GitHub. There’s just a lot of unnecessary parts and duplicated parts they have when specifically hosted for a single project, especially if there’s other infrastructure already in place. It feels kinda like running an Active Directory domain for one user and one PC (which I’m ironically considering doing, except that I have three computers).
I do agree. One thing I can think of is that it would be very nice to have a link back to the project from a linked repo. Currently something that’s sorely missing imo. But they do say it’s alpha quality though ;)
I get what you mean. I don’t mind it since I understand how it works, but for example I’m always apprehensive about clicking the submit button since I think maybe I accidentally edited some field I didn’t want to edit. There’s also some strange restrictions such having to upload attached files one by one and having to make a new comment for each of them. It’s certainly got its flaws, but the nice thing about it is that it’s a central bug database, with a lot more detailed categorization (bug status, dependencies, platforms, affected versions, product component, etc.) than what GitLab provides, which is pretty much just tags for all of those afaik, which is very valuable for a huge project like KDE. I’m not sure whether any FOSS alternatives that provide all that exist honestly.
Oh I wasn’t necessarily accusing Github, or any other service of being bloated, I was making more of a general statement.
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. I think that it encourages more community input – people can find the components that they like, and delve into that specific component, and its community without needing to worry about anything else in the ecosystem. It may be too overwhelming for someone to have to interact with everything from every other project in the ecosystem, instead of just what they are interested in.
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
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.