Review Board claims Python 3.9 and advertises 3.10 through 3.14

requires-python says 3.9 and the classifiers start at 3.10

Two fields in the same metadata block disagree about the floor:

license = { text = 'MIT' }
readme = 'README.rst'
dynamic = ['dependencies', 'version']
requires-python = '>=3.9'

The `requires-python` field is what pip enforces, so it will resolve and install on Python 3.9. The classifier list immediately below it names 3.10, 3.11, 3.12, 3.13 and 3.14, with no entry for 3.9 at all. A resolver reading the first field gets 3.9; a user reading the classifier list on a package index gets 3.10 onward. One of the two is out of date and the enforced one is the permissive one.

The same block pins a single Django version, `Framework :: Django :: 4.2`, while advertising five Python versions including 3.14. A Django 4.2 classifier next to Python 3.14 is a combination the project does not otherwise discuss, and the repository carries a release notes page rather than a compatibility matrix, so the pairing is not documented anywhere in the tree.

The rest of the classification is conventional: Production/Stable, Web Environment, Framework :: Django, Framework :: Review Board, Intended Audience :: Developers, Natural Language :: English only, and Operating System :: OS Independent.

Neither the dependency list nor the version number is in the manifest

`dynamic = ['dependencies', 'version']` means the two facts a reader normally checks first are computed rather than written down. The build backend is `buildthings.backend`, pulled in as `buildthings~=1.2`, so the dependency list and the version string are produced during the build from files elsewhere.

The practical consequence is that pyproject.toml cannot answer what Review Board needs installed. Anyone building an isolated environment has to find the real requirement list first. The repository root carries `dev-requirements.txt` and `doc-requirements.txt`, and the Makefile's only target installs the development set from `dev-requirements.txt`, but the file that supplies the runtime dependencies is not among the root entries.

What is visible in the metadata instead is a set of extras keyed by Elasticsearch client major version: `elasticsearch1` pinned to the 1.0 series, `elasticsearch2` to 2.0, `elasticsearch5` to 5.0, and `elasticsearch7` to 7. So search integration is versioned by client generation, one extra per generation, and the naming convention is the number rather than a feature name. Each is a `~=` compatible-release constraint, so an extra selects a minor range rather than pinning an exact build.

Also worth knowing: the console entry points are declared here rather than in a setup script, which is why they are easy to miss.

The Makefile has one target and none of them runs the tests

The entire build surface offered by make is:

develop:
	${PIP} install -e .
	${PIP} install -r dev-requirements.txt

Two pip invocations behind a single target named `develop`, marked `.PHONY`. There is no `all`, no `build`, no `test`, no `lint`, no `clean` and no `docs`. Running make with no arguments does nothing useful, and a contributor who expects the conventional entry points has to find them elsewhere.

Elsewhere is not far. The tree has `tox.toml` for test environments, `conftest.py` at the root, and a `tests/` directory, so the project has a real test suite with a real configuration. `Makefile`, `MANIFEST.in` and `setup.cfg` sit alongside `pyproject.toml`, which is the older layout retained for compatibility rather than a deliberate choice, and `COPYING`, `AUTHORS`, `NEWS` and `INSTALL` give the root an autotools shape that predates the pyproject migration.

The README offers no build instructions of its own. It sends you to an interactive web guide, and the only command-adjacent thing it mentions is RBTools, which is a separate client package rather than part of this build.

Three console scripts exist and the README names none of them

Installing the project puts three commands on your path:

[project.scripts]
rb-site = 'reviewboard.cmdline.rbsite:main'
rbext = 'reviewboard.cmdline.rbext:main'
rbssh = 'reviewboard.cmdline.rbssh:main'

The entry point names tell you the shape of the thing without opening the source. `rb-site` manages the site and its cluster, `rbext` manages extensions, and `rbssh` gets you a shell inside the environment. That third one is the interesting detail, because a server application that gives you an authenticated shell into its own runtime is doing something deliberate about how you inspect a live instance.

None of the three appears in the README. What the README offers instead is a pointer to a hosted interactive guide, a link to RBCommons for someone else to run it, and a demo instance to click around in. For a server product that is a defensible choice, and it is also the reason the commands stay invisible until you read the metadata.

The one command the README does treat as a product of its own is RBTools, described as a command line suite for posting changes for review, landing reviewed changes, patching your local tree with someone else's changes and checking your workload, installable on Windows, Linux, Mac and other platforms.

Patches go to a Review Board server and pull requests are refused

The repository ships a `.reviewboardrc` at its own root, so Review Board reviews itself, and the contributing section names where that review happens: patches to Review Board, RBTools and related projects are accepted on reviews.reviewboard.org, with a parenthetical note that pull requests are not accepted.

That is a defensible house rule for a tool that reviews diffs, and it has a practical consequence worth stating plainly. A contributor who opens a pull request against this repository is not following the project's process, and the path to a merged change is to register on the project's own review server and push a review request instead. The `.mailmap` at the root and the `AUTHORS` file are the other half of that arrangement, normalising author names and recording credit across a history that goes back to 2006.

Three guides are offered for new contributors, a Web API Guide, an Extending Review Board guide and a Contributor Guide, which matches the project's stated pitch that custom features, review UIs and data analysis can be built without forking. The extension model is the substantive claim here, and `rbext` in the console scripts is the command that manages it.

The repository layout supports the same split: `reviewboard/` for the Python package, `docs/` for the manuals, `contrib/` for supporting pieces, and a `.storybook/` directory plus `package.json` for the JavaScript side.

The JavaScript lint target covers one directory and ajv is pinned exactly

The JavaScript side of a Django application is substantial here, and its build surface is small:

    "private": true,
    "scripts": {
        "build-storybook": "storybook build",
        "lint": "eslint reviewboard/static/rb/js",
        "storybook": "storybook dev -p 6007 --no-open"
    },

The lint script names one path, `reviewboard/static/rb/js`. That is the traditional location for JavaScript served as static files by a Django app, so the scope looks deliberate, and it is also the only JavaScript directory the manifest checks.

Three build configurations sit in the root for that one directory: `babel.config.json`, `rollup.config.mjs` and `vite.config.mjs`, alongside `tsconfig.json`, which means the static JavaScript and the Storybook components are built by different tools. The manifest is private and named `reviewboard-root`, and it declares npm workspaces covering `reviewboard` and `.npm-workspaces/*`, the second of which is not a directory in the tree.

One override is worth noting:

    "overrides": {
        "ajv": "8.18.0"
    },

An exact version pin on a transitive dependency, with no explanation in the repository, is the standard way to hold a dependency at a fixed release while an advisory or a breaking change is worked around. The `browserslist` entry, `baseline widely available`, sets the browser floor for the bundle.

The backend list keeps ClearCase and CVS and leaves out Subversion

The systems Review Board names are Bazaar, ClearCase, CVS, Git, Mercurial, Perforce, Plastic and Azure DevOps. That is eight backends, and the set spans both ends of the version control era: CVS and ClearCase sit alongside Git and Azure DevOps.

Subversion is not among them. The list is presented without a note about removals, so a reader cannot tell whether it was never supported, is supported but unlisted, or has been dropped, and the repository has no migration note on the point.

The hosting list is separate and longer: Assembla, Beanstalk, Bitbucket, Codebase, GitHub, GitLab, Gitorious, Kiln and Unfuddle. Those are repositories the app can pull from, distinct from the version control systems it diffs. The README does not say which of the nine are still actively supported or which are listed for historical configurations, and with nine names spanning that many years of services, the omission of any maintenance status is the more useful gap to note.

Two of the three hosting destinations the project runs itself are also commercial: RBCommons, where the vendor hosts it for you, and the paid Power Pack described below.

The paid add-on sells a feature marked coming soon

Power Pack is the commercial extension, offered under a trial licence, and its feature list is worth reading as a roadmap rather than a catalogue:

* `Report generation`_ * `PDF and Office document review`_ * Better multi-server scalability * Integration with `Microsoft Azure DevOps`_ * Integration with `GitHub Enterprise`_ * LDAP/Active Directory user sync (coming soon)

The first two link to documentation pages. The last is the interesting one: a user sync feature with the word coming soon attached to it, in a list whose other entries are presented as available. A buyer reading a sales list has no way to tell which of the six are in the current build.

Support is split the same way. The public route is a discussion list, with a stated response time of within a couple of days, aimed at general questions that do not expose confidential information. The paid route is a support contract offering same-day responses, confidential communications, installation and upgrade assistance, emergency database repair, phone or chat by appointment, priority fixes for urgent bugs, and backports of urgent fixes to older releases.

That last item carries its own hedge, in the form of a parenthetical note that backports happen when possible. Everything else in the paid list is unconditional, so the single qualified promise is the one about staying on an older release, which is what a large installation with a long upgrade cycle most wants.

Editorial conclusion

Review Board is a mature server rather than a library, and the two things to check before committing are operational. The manifest declares Python 3.9 as the floor while its classifiers start at 3.10, so pip will accept an interpreter the project has not claimed. And the dependency set is not in the packaging metadata at all, since both dependencies and version are computed at build time, which means an offline or air-gapped install has to be planned from the requirements files rather than from the project description. The diff viewer is the part with real depth, interdiffs and moved-line detection go well past showing a patch, and the extension API is the reason to look if your review workflow does not fit a default.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. reviewboard/reviewboard on GitHub