Hi Andreas, Ludovic and all, Andreas Enge <[email protected]> writes:
> Am Thu, Jun 25, 2026 at 09:39:40PM +0200 schrieb Ludovic Courtès: >> Now, as someone used to email, the interface was a bit of a loss > > Well, I did not expect it, but I quite enjoy the web interface for > interactions... A few mouse clicks are okay, and then I am back to the > keyboard for making comments. > > I also like that I can get email copies of everything that happens on > Codeberg; I feel much more up to date with what happens than before, > when I did not follow Debbugs. Now I also do not read all notifications, > but due to the sorting by topic in my email client I simply delete those > that I am not interested in. Maybe if there were the option to simply > reply by email that would be even better. I've disabled the email notifications because they are non-actionable (can't reply from email) and duplicate the workload from the Codeberg web notifications. One thing I find annoying is that once you read a notification, it doesn't stay in your "inbox"; which makes them easy to read once and then forget, if you didn't have the hack time available to immediately handle it. On GitHub for example, the notifications act more like email, they can be marked read while remaining visible in your virtual "inbox", and there's a dedicate button to archive or remove them once handled (not simply just read). AGit is a bit awkward to use, especially if you are not using any tool like emacs-forgejo to ease it, but is otherwise nifty. I wouldn't expect newcomers familiar with GitHub PRs to really embrace/enjoy that interface though. The ease of applying patches is similar but superior against bitrot because the PRs can be checkout directly from git, if you need that (but I typically just apply with 'curl ...url-to-pr.patch | git am -s'). The performance of codeberg.org is often on the slow side (slow response time, errors returned, as others mentioned), but it seems to have gotten a bit better recently. I also experienced annoying rate limits e.g. when creating multiple issues in a row, I needed to wait more than 30-40 minutes! A private Forgejo instance I've been hosting privately via [0], appears to perform better and lifts the rate limits. One thing I found odd with Forgejo is the way the search works when searching for issues for example; by default it does a fuzzy match and that typically returns pages and pages on irrelevant answers in my experience; so you have to always double-quote the terms you are searching for, e.g. "something"; not only that, you need to add a '+' in front to make sure it returns matches containing it, e.g. +"something". That is documented in [1]. On the up side, Forgejo is definitely more modern, with an capable API, AGit is faster at creating PRs for multiple commits than our old send one email first, wait then send the rest flow with Debbugs, the Forgejo team is responsive and has been welcoming of small contributions of mine toward a manifest.scm file and some documentation changes, and I have hopes that emacs-forgejo will alleviate the potential risk of RSI that the browser point-and-click user interface could otherwise invite. I'm also enjoying its simple project organization (e.g. Kanban view) and time accounting features, although spartan compared to more powerful tools like Redmine. [0] https://codeberg.org/guix/guix/pulls/9006 [1] https://forgejo.org/docs/latest/user/issue-search/ -- Thanks, Maxim
