Borg good

I have found that instances that do seem to modify the source code just use the existing “Code” link and simply point it to their own repo instead.

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.

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 use Nextcloud’s Calendar to sync to other calendar apps over CalDAV.

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.

I’m mostly just asking out of curiosity.

I’m not familiar with Sourcehut. Why do you recommend it specifically?

occ files:scan --all (or something like that)

I have already done this, as was mentioned in the post.

I enabled that in /var/snap/nextcloud/current/nextcloud/config/config.php with 'filesystem_check_changes' => 1,, but it did not fix the issue. It did seem to remove one error that was popping up, but I am still getting a prompt stating that the file could not be created (which is strange because, when I did a file scan, it shows that they were created), and the files are still not displayed.

It should also be noted that I restart nextcloud after applying the changes with # snap restart nextcloud.

Tried this. Still nothing.

for example to 777 as a temporary solution

Just tried this, and still nothing.

# chmod -R 777 data-directory

Has there been any discussion around possibly switching over to the afformentioned alternative services?

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.