An absolute deal breaker for me is having code review comments being part of the repository itself. Anything that stores this extremely valuable historical content on a mailing list, in a database silo or in some other extra layer which isn’t pinned by the hash of the HEAD commit is, fundamentally, the same kind of risk as GitHub. Fossil is part-way here. It does issues, but not code reviews (https://fossil-scm.org/home/doc/tip/www/contribute.wiki), it’s still patches over email.
Once you have that info in VCS, you can add a snazzy web ui, rss feed and a mailing list on top, of course.
The second feature is built-in support for merge queue. For non-trivial projects, individual contributors should not push to the main branch. They only need to mark specific commits as “ready to be integrated”, and robots should be responsible for serializing all suggested changes, optimally scheduling CI for them, and advancing main to known-good hashes.
One more thing I need: a clear approach for dealing with spam and abuse.
It is important that anyone can create an account and open an issue, but it also ia important that there’s no spam.
Right now GitHub delivers that: you get spam once in a while, but it is removed very quickly after an abuse report. I would guess that behind this is a pile of automation plus an actual human triage team?
Does anything currently keep the code review comments in the repo? I've been looking at fossil lately as a "forge" (I kinda hate that term) for my hobby projects; I don't expect to have much from outside contributors so code reviews are more of a nice-to-have.
In this system, review comments are no different from any other comment, except that they only live in a review patch-series and are expected to be deleted before merging.
An absolute deal breaker for me is having code review comments being part of the repository itself.
This is a really interesting idea. Curious how you would imagine it handling rewritten history, like if I force push a branch or do a squash merge, what do comments get "anchored" to afterward to let users find them? In GitHub, that's the Pull Request, I can still view the discussion even if the included commits have changed. Would this system still have a separate concept of a PR (or whatever you want to call it), just stored in the repo? Or were you hoping for something that integrated more tightly?
A review is a commit that contains a git tree with comments (either as a single machine-readable comments.json, or maybe something more human-editable, like a file per comment thread)
A review commit has code being reviewed as a parent (but not the actual parent's tree)
Therefore, for every commit in a review, its clear which revision it talks about, so file:line:column references make sense
When comments are added to the review, a new review commit is created, which contains only added comments, and has two parents --- the code being reviewed, and the previous review
Review commits are created by "tooling" and so a linear history for review is enforced
One way to do this is to say that reviews are append only, and each review tree contains only new comments. The full set of comments requires you walking the parents, and "merge conflicts" can be resolved by ordering two concurrent review commits arbitrary, essential set-merging comments
This way, from the latest review comment, all previous reviews states, and all previous states of code being reviewed are reachable
It's up to the front-end to look at the full set of comments and their associated commits, and to figure out where in the UI they should be displayed
When you merge a PR into main, the merge commit has three parents: the previous mainline commit, the commit corresponding to the latest iteration of the branch, and the commit corresponding to the latest iteration of review (which transitively pulls all the previous versions of the branch).
Using both Gerrit & email, it’s a shame the “pull request” model is the most dominant—especially where maintainer just leave nitpicks as comments instead of just making those changes as the contributor probably doesn’t care that much about the style. …But why am missing is any non-email workflow for either Darcs or Pijul which I have been using more & more.
I wish I could see something based on XMPP instead of email where you can get real-time, decentralized collaboration on a WIP patch (one patchset per MUC? & MUCs could open like voice chat, hats, attachments, reactions, search, MAM, moderation, tombstoning when done—all already defined XEPs) while having PubSub for subscriptions, along with using it as a transport to CI. It would require its own cilent to be practical, but a lot of features would just work™ even on any client. …Realistically I think this is just having a recent affinity for this old, federated tech being extended in surprising ways.
Communication with the code submitter is very high latency (sometimes weeks or months!) and unreliable (people submit a PR and disappear). The Github model that assumes a back-and-forth interaction completely breaks down.
I'd like to be able to edit code as I review it, and have it amend (git-absorb). If there's a minor issue like a typo, having a back and forth with the submitter is a waste of time. Edit Suggestion hack on Github is fiddly and spams history.
I don't want to re-review the same code. If there's a problem with one function or one commit, I want to pre-approve the rest and not have to rereview it when submitter force-pushes a fix.
I want to be able to merge a part of a PR, or remove commits from it, without closing the PR. Sometimes I don't want a feature, but some groundwork done for it is useful to keep. Sometimes the opposite - people throw in unnecessary "cleanups" or reformatting.
I would like others to be able to collaborate on PRs and refine them, address issues if the original submitter doesn't. This is theoretically already possible in the Github model, but in practice making PRs for other PRs is an obscure trick, and the code and notifications about it are invisible to the target project. When people fork and submit modified PRs this just creates chaos and merge conflicts.
I often have a situation where submitted code is okay-ish, but I'd like some minor improvements. This is frustrating to the person submitting the PR, because their PR is held hostage until they do all the nice-to-have polishing. It's a dilemma for the maintainer, because merging immediately risks submitter disappearing and never doing follow up improvements. I'm not sure exactly how, but I'd like some way of tentatively merging a PR with an obligation to do cleanups later (maybe it could get merged to some staging branch but not get chery-picked to a stable branch until FIXMEs are resolved?)
popular open-source projects can be stuck with a situation where there's 1 person that can review and approve code to move the project forward and 500 people eager to contribute something and help each other. GitHub's model completely fails to capitalize on the surplus of interested contributors. Instead of helping them collaborate, it turns the situation into a crisis, chaos, and an angry pile-on. There needs to be a better way of managing forks and copying code across forks to let others experiment and move the project forward without being blocked by the single maintainer, in a way that helps the maintainer pick changes that have been proven popular and working across the forks.
Edit Suggestion hack on Github is fiddly and spams history.
Not sure if you are aware, but unless the PR submitter enabled the setting to prevent it (IIRC organizations have it by default), as a repository owner you can push in the PR branches, hence you can do these clean edits yourself with a force push.
I do it all the time for small edits that aren't worth a back and forth.
Zero effort CICD setup. make buildmake testmake upload as the only steps. Let me put the rest in my makefile (I'll go out to a better build system from there). Let me go from idea to published running artifact in 2 minutes or less.
Why even bother with Make, of which there are different versions. Instead of a config file at a well-known location, which is what most CI/CD systems do (.github/actions/..., .cloudbuild.yaml, etc.), make it three shell scripts with well-known names in a well-known directory. As a bonus, you could make them .bat files for Windows builds if you wanted that.
Because the first rule of CI is that you shouldn't have CI. And the second rule is that if you need CI, then you just call to executables you can run locally.
Your proposal only works if you create a new DSL that works locally first and foremost. And that specific proposal (YAML DSL + runner) has been tried and seen fail too many times.
I want security advisories that have rails to ensure quality data is published, a commit oriented ecosystem so that all projects can publish meaningful data, and an integration that allows for direct cve publication (for those that want to).
A web UI without any javascript, that renders nicely in something in w3m, chawan (so you get a TUI "for free") etc. Where you're able to interact with the project and create PRs. Something a non-technical user can use.
PR system with everything stored in the VCS itself
I have no strong opinion on the change flow, but it should be exposed in such a way that it's easy to edit using $EDITOR, so you can expose a command forge review XXXX where you can review each file in $EDITOR and then leave an approval at the end.
Easy way to add protected files and branches
CI done with just shell-scripts. A shell-script post-receive hook is good enough for me, maybe just integrate the results into the web UI and way to rerun jobs.
Configuration via files for easy backup, including CI secrets managed with sops.
This would be for cathedral style development. For bazaar-style, I think regular git with email-list is fine, like with Sourcehut.
Mercurial and its "topic" extension allows to collaboratively edit a stack of commits, instead of just sending reviews and wait for the author to edit. Combined with evolve/rebase commands that usually work without arguments (!), it is very comfy and it kinda reduces the need for a forge.
But they have a forge, Heptapod (a Gitlab fork adding Mercurial support), where every time someone pushes a new version of changes stack, you can "Compare with previous version" - see for example https://foss.heptapod.net/mercurial/mercurial-devel/-/merge_requests/1943
Shall I tell you one of the three main reasons why I don’t have a fediverse account? The addresses are awful. If I go for @me@chrismorgan.info like my primary email address, I believe it may show up to some people as just “@me”. If I go for @chrismorgan@chrismorgan.info… ugh. This is something that ATProto got very right, domain names are great as handles, and subdomains are entirely adequate for multiple users. (I don’t have an account there either… but that’s another story.)
Actually… huh, I suppose you could go logically single-user even for a shared forge, by using subdomains. Just imagine chris-morgan.github.com instead of github.com/chris-morgan… could be fun. Anyway, back to the topic.
Aesthetics matter.
Also going single-user can have far-reaching consequences. Take something like Mastodon and try to trim it down to a single user, and it’s still going to be a hog (or elephant, if you prefer). Fediverse projects that were designed for a single user work better at that use case.
So, I say: I want to run my own server and have no other local users, and no compromises because of the potential for other users. This also means I want to push as username chris as I do with normal SSH, not as a generic username like git as forges do.
In order for it to be a forge as commonly understood, federation is obviously required. But I want one’s “home server” to have only a single local user.
I had some thoughts on my head for a while, this post inspired me to write them down.
Copying for convenience:
Merge queue-oriented
(This is mostly inspired by Gerrit.)
The forge should provide a merge queue implementation. The merge queue should work around individual commits.
The forge scans continuously for new commits targetting a branch. If a commit is mergeable to main, then the forge runs static validation on the merge of the commit to the target branch. Commits that pass human validation requirements and static validation, get merged to their target branch.
The forge should make it easy to list pending merge changes with clear display and filtering of unmet merge requirements.
Change-id aware
All features of the forge that can benefit from change-id usage should do that.
I want to be able to list the tags/releases with a specific change.
I want the forge to mark a change as "pending deployment" when the change is in main, but not in the "production" branch, and mark the change as "done" when the change is in the production branch.
Author as approver option
The forge should allow configuration where a change submitter can approve their own changes.
For example, you might establish that all changes need a reviewer, but authors are (socially) allowed to approve their own trivial changes (e.g. typo fixes, etc.).
(Lack of author approval might also be treated as a sort of "draft" status.)
Commit message review
(Also present in Gerrit.)
Commit messages should be reviewable/editable in the forge just like the rest of a change.
For a leading and trusty open source forge I want it to have reproducible or at least hermetic CI/CD option. I mean mainly that the build script can only see things that are declared upfront. Everything must be downloaded and hashes checked before the script runs. This with github pages alike makes for a simple (not easy to get there) infrastructure you can count on.
I'm not really sure how viable all that is, but for some builds, for some programming languages implementations it should be possible and then the project could have a nice little reproducible badge to show off.
Being able to do code reviews locally in your editor of choice, instead of being forced into some clunky web interface that uses a font you can't change and syntax highlighting that looks horrible.
My current workflow for this involves some custom Neovim tooling so I can have nice side-by-side diffs and a git pr command to check out a pull request, but the moment I'd want more (e.g. being able to leave review comments) I'd end up having to use some random person's unlikely-to-still-be-maintained-5-years-from-now CLI/thing that talks to the GitHub API.
Or more precisely, we need more local-first tools that don't just run locally (as in you can run it locally but it's a PITA) but also integrate locally with editors and what not.
The reason this isn't likely to be a first-class citizen is because of the effort it would require: a single web interface "works" (by virtue of forcing it upon users) across all platforms and editing environments, but a more tightly integrated setup means that for N editors/environments/whatever you need N integrations.
The same applies to CI: I want to be able to easily run my tests across say Linux, FreeBSD and macOS without first having to push some commit(s) to a branch and then having to wait 15 minutes for them to get picked up. run-remotely some-command --on freebsd,linux,mac or something to that extent. Basically a local-first/non-centralized CI system that does still support a centralized system as a single source of truth (= to ensure all code goes through the same "blessed" system before being merged). Note that this goes beyond just ssh user@host command ... because it involves copying over the source code, caching, installing the necessary dependencies, etc so you get the same reliable state every time.
matklad | 4 hours ago
An absolute deal breaker for me is having code review comments being part of the repository itself. Anything that stores this extremely valuable historical content on a mailing list, in a database silo or in some other extra layer which isn’t pinned by the hash of the HEAD commit is, fundamentally, the same kind of risk as GitHub. Fossil is part-way here. It does issues, but not code reviews (https://fossil-scm.org/home/doc/tip/www/contribute.wiki), it’s still patches over email.
Once you have that info in VCS, you can add a snazzy web ui, rss feed and a mailing list on top, of course.
The second feature is built-in support for merge queue. For non-trivial projects, individual contributors should not push to the main branch. They only need to mark specific commits as “ready to be integrated”, and robots should be responsible for serializing all suggested changes, optimally scheduling CI for them, and advancing main to known-good hashes.
The third feature would be CI as heterogeneous (windows + MacOS + whatever) task runner with isolation, a-la https://gregoryszorc.com/blog/2021/04/07/modern-ci-is-too-complex-and-misdirected/
matklad | 4 hours ago
One more thing I need: a clear approach for dealing with spam and abuse.
It is important that anyone can create an account and open an issue, but it also ia important that there’s no spam.
Right now GitHub delivers that: you get spam once in a while, but it is removed very quickly after an abuse report. I would guess that behind this is a pile of automation plus an actual human triage team?
jfloren | 4 hours ago
Does anything currently keep the code review comments in the repo? I've been looking at fossil lately as a "forge" (I kinda hate that term) for my hobby projects; I don't expect to have much from outside contributors so code reviews are more of a nice-to-have.
technomancy | 3 hours ago
The first system I heard of which does this is git-pr: https://pr.pico.sh/
In this system, review comments are no different from any other comment, except that they only live in a review patch-series and are expected to be deleted before merging.
matklad | 4 hours ago
There’s git-apprise:
https://github.com/google/git-appraise
But https://blog.buenzli.dev/flirt-native-backend/#why-using-git-notes-is-a-bad-idea very convincingly argues that the implementation took a very wrong approach.
georgelesica | 3 hours ago
This is a really interesting idea. Curious how you would imagine it handling rewritten history, like if I force push a branch or do a squash merge, what do comments get "anchored" to afterward to let users find them? In GitHub, that's the Pull Request, I can still view the discussion even if the included commits have changed. Would this system still have a separate concept of a PR (or whatever you want to call it), just stored in the repo? Or were you hoping for something that integrated more tightly?
matklad | 2 hours ago
Spitballing (and riffing off flirt heavily here):
treewith comments (either as a single machine-readablecomments.json, or maybe something more human-editable, like a file per comment thread)parent's tree)file:line:columnreferences make sensetreecontains only new comments. The full set of comments requires you walking the parents, and "merge conflicts" can be resolved by ordering two concurrent review commits arbitrary, essential set-merging commentstoastal | 5 hours ago
Using both Gerrit & email, it’s a shame the “pull request” model is the most dominant—especially where maintainer just leave nitpicks as comments instead of just making those changes as the contributor probably doesn’t care that much about the style. …But why am missing is any non-email workflow for either Darcs or Pijul which I have been using more & more.
I wish I could see something based on XMPP instead of email where you can get real-time, decentralized collaboration on a WIP patch (one patchset per MUC? & MUCs could open like voice chat, hats, attachments, reactions, search, MAM, moderation, tombstoning when done—all already defined XEPs) while having PubSub for subscriptions, along with using it as a transport to CI. It would require its own cilent to be practical, but a lot of features would just work™ even on any client. …Realistically I think this is just having a recent affinity for this old, federated tech being extended in surprising ways.
kornel | 2 hours ago
Code review and approval is the bottleneck.
Communication with the code submitter is very high latency (sometimes weeks or months!) and unreliable (people submit a PR and disappear). The Github model that assumes a back-and-forth interaction completely breaks down.
I'd like to be able to edit code as I review it, and have it amend (git-absorb). If there's a minor issue like a typo, having a back and forth with the submitter is a waste of time. Edit Suggestion hack on Github is fiddly and spams history.
I don't want to re-review the same code. If there's a problem with one function or one commit, I want to pre-approve the rest and not have to rereview it when submitter force-pushes a fix.
I want to be able to merge a part of a PR, or remove commits from it, without closing the PR. Sometimes I don't want a feature, but some groundwork done for it is useful to keep. Sometimes the opposite - people throw in unnecessary "cleanups" or reformatting.
I would like others to be able to collaborate on PRs and refine them, address issues if the original submitter doesn't. This is theoretically already possible in the Github model, but in practice making PRs for other PRs is an obscure trick, and the code and notifications about it are invisible to the target project. When people fork and submit modified PRs this just creates chaos and merge conflicts.
I often have a situation where submitted code is okay-ish, but I'd like some minor improvements. This is frustrating to the person submitting the PR, because their PR is held hostage until they do all the nice-to-have polishing. It's a dilemma for the maintainer, because merging immediately risks submitter disappearing and never doing follow up improvements. I'm not sure exactly how, but I'd like some way of tentatively merging a PR with an obligation to do cleanups later (maybe it could get merged to some staging branch but not get chery-picked to a stable branch until FIXMEs are resolved?)
popular open-source projects can be stuck with a situation where there's 1 person that can review and approve code to move the project forward and 500 people eager to contribute something and help each other. GitHub's model completely fails to capitalize on the surplus of interested contributors. Instead of helping them collaborate, it turns the situation into a crisis, chaos, and an angry pile-on. There needs to be a better way of managing forks and copying code across forks to let others experiment and move the project forward without being blocked by the single maintainer, in a way that helps the maintainer pick changes that have been proven popular and working across the forks.
byroot | 11 minutes ago
Not sure if you are aware, but unless the PR submitter enabled the setting to prevent it (IIRC organizations have it by default), as a repository owner you can push in the PR branches, hence you can do these clean edits yourself with a force push.
I do it all the time for small edits that aren't worth a back and forth.
Vaelatern | 4 hours ago
Zero effort CICD setup.
make buildmake testmake uploadas the only steps. Let me put the rest in my makefile (I'll go out to a better build system from there). Let me go from idea to published running artifact in 2 minutes or less.georgelesica | 3 hours ago
Why even bother with Make, of which there are different versions. Instead of a config file at a well-known location, which is what most CI/CD systems do (
.github/actions/...,.cloudbuild.yaml, etc.), make it three shell scripts with well-known names in a well-known directory. As a bonus, you could make them .bat files for Windows builds if you wanted that.viccuad | 2 hours ago
Because the first rule of CI is that you shouldn't have CI. And the second rule is that if you need CI, then you just call to executables you can run locally.
Your proposal only works if you create a new DSL that works locally first and foremost. And that specific proposal (YAML DSL + runner) has been tried and seen fail too many times.
Yogurt | 3 hours ago
I want security advisories that have rails to ensure quality data is published, a commit oriented ecosystem so that all projects can publish meaningful data, and an integration that allows for direct cve publication (for those that want to).
mccd | 3 hours ago
In my wishlist, I have:
$EDITOR, so you can expose a commandforge review XXXXwhere you can review each file in$EDITORand then leave an approval at the end.This would be for cathedral style development. For bazaar-style, I think regular git with email-list is fine, like with Sourcehut.
martinkirch | 2 hours ago
Mercurial and its "topic" extension allows to collaboratively edit a stack of commits, instead of just sending reviews and wait for the author to edit. Combined with evolve/rebase commands that usually work without arguments (!), it is very comfy and it kinda reduces the need for a forge. But they have a forge, Heptapod (a Gitlab fork adding Mercurial support), where every time someone pushes a new version of changes stack, you can "Compare with previous version" - see for example https://foss.heptapod.net/mercurial/mercurial-devel/-/merge_requests/1943
they presented this approach in 15 minutes at Fosdem'25 https://archive.fosdem.org/2025/schedule/event/fosdem-2025-5989-a-glimpse-into-a-smoother-version-control-experience/
chrismorgan | an hour ago
Single-user, or at least single-user mode. Why should I suffer URLs like https://code.chrismorgan.example/chrismorgan/repository-name, when it could be https://code.chrismorgan.example/repository-name?
I’m absolutely serious about this. And there are clearly plenty of people that want such a thing, going by https://github.com/go-gitea/gitea/issues/11028.
Shall I tell you one of the three main reasons why I don’t have a fediverse account? The addresses are awful. If I go for @me@chrismorgan.info like my primary email address, I believe it may show up to some people as just “@me”. If I go for @chrismorgan@chrismorgan.info… ugh. This is something that ATProto got very right, domain names are great as handles, and subdomains are entirely adequate for multiple users. (I don’t have an account there either… but that’s another story.)
Actually… huh, I suppose you could go logically single-user even for a shared forge, by using subdomains. Just imagine chris-morgan.github.com instead of github.com/chris-morgan… could be fun. Anyway, back to the topic.
Aesthetics matter.
Also going single-user can have far-reaching consequences. Take something like Mastodon and try to trim it down to a single user, and it’s still going to be a hog (or elephant, if you prefer). Fediverse projects that were designed for a single user work better at that use case.
So, I say: I want to run my own server and have no other local users, and no compromises because of the potential for other users. This also means I want to push as username chris as I do with normal SSH, not as a generic username like git as forges do.
In order for it to be a forge as commonly understood, federation is obviously required. But I want one’s “home server” to have only a single local user.
koala | an hour ago
I had some thoughts on my head for a while, this post inspired me to write them down.
Copying for convenience:
Merge queue-oriented
(This is mostly inspired by Gerrit.)
The forge should provide a merge queue implementation. The merge queue should work around individual commits.
The forge scans continuously for new commits targetting a branch. If a commit is mergeable to main, then the forge runs static validation on the merge of the commit to the target branch. Commits that pass human validation requirements and static validation, get merged to their target branch.
The forge should make it easy to list pending merge changes with clear display and filtering of unmet merge requirements.
Change-id aware
All features of the forge that can benefit from change-id usage should do that.
I want to be able to list the tags/releases with a specific change.
I want the forge to mark a change as "pending deployment" when the change is in main, but not in the "production" branch, and mark the change as "done" when the change is in the production branch. Author as approver option
The forge should allow configuration where a change submitter can approve their own changes.
For example, you might establish that all changes need a reviewer, but authors are (socially) allowed to approve their own trivial changes (e.g. typo fixes, etc.).
(Lack of author approval might also be treated as a sort of "draft" status.)
Commit message review
(Also present in Gerrit.)
Commit messages should be reviewable/editable in the forge just like the rest of a change.
hawski | 57 minutes ago
For a leading and trusty open source forge I want it to have reproducible or at least hermetic CI/CD option. I mean mainly that the build script can only see things that are declared upfront. Everything must be downloaded and hashes checked before the script runs. This with github pages alike makes for a simple (not easy to get there) infrastructure you can count on.
I'm not really sure how viable all that is, but for some builds, for some programming languages implementations it should be possible and then the project could have a nice little reproducible badge to show off.
calvin | 35 minutes ago
I really liked Nesbitt’s article on the topic. In particular, better communication with downstreams.
icefox | 32 minutes ago
Support for non-git version control systems.
Ability to import and export issues/wikis/etc in some convenient format, so you're not locked into that one system.
Easily self-hostable.
yorickpeterse | 10 minutes ago
Being able to do code reviews locally in your editor of choice, instead of being forced into some clunky web interface that uses a font you can't change and syntax highlighting that looks horrible.
My current workflow for this involves some custom Neovim tooling so I can have nice side-by-side diffs and a
git prcommand to check out a pull request, but the moment I'd want more (e.g. being able to leave review comments) I'd end up having to use some random person's unlikely-to-still-be-maintained-5-years-from-now CLI/thing that talks to the GitHub API.Or more precisely, we need more local-first tools that don't just run locally (as in you can run it locally but it's a PITA) but also integrate locally with editors and what not.
The reason this isn't likely to be a first-class citizen is because of the effort it would require: a single web interface "works" (by virtue of forcing it upon users) across all platforms and editing environments, but a more tightly integrated setup means that for N editors/environments/whatever you need N integrations.
The same applies to CI: I want to be able to easily run my tests across say Linux, FreeBSD and macOS without first having to push some commit(s) to a branch and then having to wait 15 minutes for them to get picked up.
run-remotely some-command --on freebsd,linux,macor something to that extent. Basically a local-first/non-centralized CI system that does still support a centralized system as a single source of truth (= to ensure all code goes through the same "blessed" system before being merged). Note that this goes beyond justssh user@host command ...because it involves copying over the source code, caching, installing the necessary dependencies, etc so you get the same reliable state every time.