Review threads that hold their place
A thread anchors to a path, a line, a side, and the commit it was written against. Rebase the branch and it follows the line, or marks itself outdated and stays readable.
The forge that takes review seriously
Most forges treat review as a tab on a pull request. ReviewOS is built around it, on hardware you own.
# Bun, PostgreSQL and git are installed and started for you
$ ./buddy setup
$ ./buddy dev
# then push the way you already do
$ git remote add origin https://reviewos.localhost/you/project.git
$ git push -u origin mainReview is where the time goes, and where the tools give up
A hundred-file diff loads slowly, a rebase drops half the conversation, and a large change arrives as one unreviewable lump because splitting it is more work than explaining it.
- Threads anchored to a commit, so a rebase moves them instead of losing them.
- Stacks as a first class object, so a big change can arrive in reviewable pieces.
- Server-rendered diffs, so the size of the change is the reviewer's problem and not the browser's.
What that means concretely
The decisions below are the ones that make review better or worse. Everything else follows from them.
Stacked pull requests
Dependent changes that merge in order. Each one diffs against its parent, so it shows only its own work.
- Merging a parent retargets its children
- Merge the whole stack in one action
- Detected from branch topology on push
Diffs against the merge base
Not against the base tip. The difference is every change you did not make, quietly added to your review.
Rendered on the server
The browser receives HTML, not a diff library and a JSON payload. A hundred files stays usable.
Ordinary bare repositories
Driven by the git binary, on your disk. Nothing about your history is locked inside this application.
One Postgres, one process
No queue cluster to operate before the first repository exists. Scale the parts that need it, later.
Where it is
Early, and honest about it
Phases are ordered by dependency. Phase 4 is the reason this exists; phases 1 and 2 are what it needs underneath. Boxes get ticked when the work is done, not when it is planned.
00
Bootstrap
Done
01
Users, organizations, teams
In progress
02
Repositories and git hosting
Planned
03
Issues
Planned
04
Pull requests and reviews
Planned
05
Notifications and webhooks
Planned
Deliberately not doing
Saying so keeps these from being re-proposed every few weeks, and keeps the roadmap readable.
A package registry
Not until the forge itself is good.
A wiki
Markdown in the repository covers most of it.
Its own CI runners
A status API first, so your existing CI reports in. Running untrusted code is a security project of its own.
Federation, yet
An open question with a real answer owed, not a checkbox to claim.
Self-hosting
One command, on your own machine
Pantry installs and starts the toolchain, creates the database from your environment file, and runs the migrations. Nothing needs to be installed first.
Bun 1.3.14
PostgreSQL 17
git 2.47
MIT
$ git clone https://github.com/ReviewOS/reviewos.org.git
$ cd reviewos.org
$ ./buddy setup
# PostgreSQL started, database created, migrations applied
$ ./buddy dev