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?
@Kalcifer we use gitlab community edition which is completely open. Gitlab offered us a free ultimate subscription but we decided to keep using the 100% open source version instead.
Gitlab offered us a free ultimate subscription but we decided to keep using the 100% open source version instead.
⠀⠀⠘⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⡜⠀⠀⠀ ⠀⠀⠀⠑⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⡔⠁⠀⠀⠀ ⠀⠀⠀⠀⠈⠢⢄⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣀⠴⠊⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠀⢸⠀⠀⠀⢀⣀⣀⣀⣀⣀⡀⠤⠄⠒⠈⠀⠀⠀⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠀⠘⣀⠄⠊⠁⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ ⠀ ⣿⣿⣿⣿⣿⣿⣿⣿⡿⠿⠛⠛⠛⠋⠉⠈⠉⠉⠉⠉⠛⠻⢿⣿⣿⣿⣿⣿⣿⣿ ⣿⣿⣿⣿⣿⡿⠋⠁⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠉⠛⢿⣿⣿⣿⣿ ⣿⣿⣿⣿⡏⣀⠀⠀⠀⠀⠀⠀⠀⣀⣤⣤⣤⣄⡀⠀⠀⠀⠀⠀⠀⠀⠙⢿⣿⣿ ⣿⣿⣿⢏⣴⣿⣷⠀⠀⠀⠀⠀⢾⣿⣿⣿⣿⣿⣿⡆⠀⠀⠀⠀⠀⠀⠀⠈⣿⣿ ⣿⣿⣟⣾⣿⡟⠁⠀⠀⠀⠀⠀⢀⣾⣿⣿⣿⣿⣿⣷⢢⠀⠀⠀⠀⠀⠀⠀⢸⣿ ⣿⣿⣿⣿⣟⠀⡴⠄⠀⠀⠀⠀⠀⠀⠙⠻⣿⣿⣿⣿⣷⣄⠀⠀⠀⠀⠀⠀⠀⣿ ⣿⣿⣿⠟⠻⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠶⢴⣿⣿⣿⣿⣿⣧⠀⠀⠀⠀⠀⠀⣿ ⣿⣁⡀⠀⠀⢰⢠⣦⠀⠀⠀⠀⠀⠀⠀⠀⢀⣼⣿⣿⣿⣿⣿⡄⠀⣴⣶⣿⡄⣿ ⣿⡋⠀⠀⠀⠎⢸⣿⡆⠀⠀⠀⠀⠀⠀⣴⣿⣿⣿⣿⣿⣿⣿⠗⢘⣿⣟⠛⠿⣼ ⣿⣿⠋⢀⡌⢰⣿⡿⢿⡀⠀⠀⠀⠀⠀⠙⠿⣿⣿⣿⣿⣿⡇⠀⢸⣿⣿⣧⢀⣼ ⣿⣿⣷⢻⠄⠘⠛⠋⠛⠃⠀⠀⠀⠀⠀⢿⣧⠈⠉⠙⠛⠋⠀⠀⠀⣿⣿⣿⣿⣿ ⣿⣿⣧⠀⠈⢸⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠟⠀⠀⠀⠀⢀⢃⠀⠀⢸⣿⣿⣿⣿ ⣿⣿⡿⠀⠴⢗⣠⣤⣴⡶⠶⠖⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣀⡸⠀⣿⣿⣿⣿ ⣿⣿⣿⡀⢠⣾⣿⠏⠀⠠⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠛⠉⠀⣿⣿⣿⣿ ⣿⣿⣿⣧⠈⢹⡇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣰⣿⣿⣿⣿ ⣿⣿⣿⣿⡄⠈⠃⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⣠⣴⣾⣿⣿⣿⣿⣿ ⣿⣿⣿⣿⣧⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⣠⣾⣿⣿⣿⣿⣿⣿⣿⣿⣿ ⣿⣿⣿⣿⣷⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⣴⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿ ⣿⣿⣿⣿⣿⣦⣄⣀⣀⣀⣀⠀⠀⠀⠀⠘⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿ ⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣷⡄⠀⠀⠀⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿ ⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣧⠀⠀⠀⠙⣿⣿⡟⢻⣿⣿⣿⣿⣿⣿⣿⣿⣿ ⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⠇⠀⠁⠀⠀⠹⣿⠃⠀⣿⣿⣿⣿⣿⣿⣿⣿⣿ ⣿⣿⣿⣿⣿⣿⣿⣿⡿⠛⣿⣿⠀⠀⠀⠀⠀⠀⠀⠀⢐⣿⣿⣿⣿⣿⣿⣿⣿⣿ ⣿⣿⣿⣿⠿⠛⠉⠉⠁⠀⢻⣿⡇⠀⠀⠀⠀⠀⠀⢀⠈⣿⣿⡿⠉⠛⠛⠛⠉⠉ ⣿⡿⠋⠁⠀⠀⢀⣀⣠⡴⣸⣿⣇⡄⠀⠀⠀⠀⢀⡿⠄⠙⠛⠀⣀⣠⣤⣤⠄Has there been any discussion around possibly switching over to the afformentioned alternative services?
Has there been any discussion around possibly switching over to the afformentioned alternative services?
Why would there be? Your argument of “not entirely open” does not apply as you’ve just read.
I’m mostly just asking out of curiosity.
Well their instance is open though, it’s just that the official Gitlab instance has more features that aren’t released in the OSS repository of the Gitlab software.
Still, if/when forge federation happens, I think it would be amazing if all major organizations that self-host their forge used one that supports this new feature (Forgejo), so the need to make all those sign-ups, usually just to open a single issue (shudder), on a million websites would finally vanish.
Who knows, if the idea picks up, eventually we might see it implemented into Gitlab too!Well their instance is open though, it’s just that the official Gitlab instance has more features that aren’t released in the OSS repository of the Gitlab software.
I wasn’t intending to accuse KDE of using proprietary software! I apologize if it came across this way. My gripe is primarily with what you specified regarding GitLab itself.
Ah yes, I understand.
What is your concern with Gitlab exactly though? Is it relying on open core software that makes it seem fickle to you, maybe?
I don’t know, but I find Gitea/Codeberg much more pleasant to use than Gitlab, and would support such a move.
Either way, I look forward to federated identities for this stuff.
I’d love to see Sourcehut myself tbh. But yeah, Gitlab is so annoying to navigate plus the need to have a fork of a repo on their server just to submit a single change is so annoying and leads to thousands of duplicate inactive repos which clog up the search results.
No email workflow please, I’m glad we got rid off that. It’s my one major painpoint of SourceHut.
Personally I think it’s so much better than PRs (not that I don’t think it can’t be improved), but to each their own I suppose. I’d also be happy if GitLab had an HTTP endpoint you could submit a single patch or an archive of patches to, or something like that.
(Apparently it does support submitting patch files directly. Via email, but not in the git send-email format. Weird. Will have to try it at some point.)
Afaik Gitlab has a CLI tool (maybe unoffcial, idk) that allows you to create MR’s from the commandline. I don’t believe you have to use the web interface.
I’ll have to look into that. Thanks!
I’m not familiar with Sourcehut. Why do you recommend it specifically?
It’s a set of components (projects “hub.sr.ht”, wiki “man.sr.ht”, git repos “git.sr.ht”, mercurial repos “hg.sr.ht”, build service “builds.sr.ht”, bug trackers “todo.sr.ht”, mailing lists “lists.sr.ht”, I think that’s the main ones at least) which can be installed separately as needed (though at least the wiki is powered by version control so I think it needs at least one of the repo services). Everything created in these components is also separate except for projects which tie together multiple repos, lists, issue trackers and so on (for example, see https://sr.ht/~sircmpwn/sourcehut/ which is the main sourcehut project), as opposed to a strict “1 issue tracker per git repo” as with gitlab and a lot of the other “all in one” services.
It also emphasizes the git send-email workflow as opposed to the (in my opinion, supremely convoluted and annoying) PR workflow, which means you can just clone the repo, make your changes locally, and send patches. (Though you can still fork, push and then submit patches from the web interface if you want to, to get something similar to PRs.)
So KDE at the minimum could just have hub + git + lists (for patches), and keep Bugzilla as the single bug tracker, for example.
The builds/CI service is also supposedly excellent, but I have to say I haven’t used it yet and KDE is already using Jenkins anyway. Though of course, it does integrate with the other parts, CI for each commit and incoming patch set which is still useful to have. I think KDE is currently using GitLab CI/CD also.
I think that’s the main big parts, there’s more info about its features on the main website: https://sourcehut.org.
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.
So KDE at the minimum could just have hub + git + lists (for patches), and keep Bugzilla as the single bug tracker, for example.
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.
many services unfortunately go the route of trying to make an “everything app” which often leads to bloat
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 will say that, compared to the usual git services (Gitlab, Github, Gitea, etc.) it is severely lacking polish.
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 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 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.
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.
Oh I wasn’t necessarily accusing Github, or any other service of being bloated, I was making more of a general statement.
the nice thing about it is that it’s a central bug database
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.
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
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.
