Browser Engine Patcher

Home/Community

Community

There is no chat server, no mailing list and no account system. Everything happens in the project repository: issues, patch proposals, review threads and release planning. This page explains how to take part and what makes a report easy to act on.

Report a problem

Before writing, run bep doctor --json and keep the output. A useful report contains the BEP version, the engine family and revision, the patch identifiers in your series, the command you ran, the full error block, and the last 40 lines of the log at --log-level debug. If the failure is a hash mismatch, attach the output of bep verify --manifest; it is short and it usually points at the file with the wrong line endings.

Propose a patch

A patch proposal is a file in the series format plus a short note explaining the problem it solves for extension developers. Reviews look for four things:

  1. One purpose. If the diff touches the build system and the renderer, it is probably two patches.
  2. No release-build behaviour change. Debug hooks must be behind a define; visual changes must be opt-in through a profile.
  3. A stated base. The patch header names the upstream revision it was written against, even when the hunk is context-free.
  4. A test note. One paragraph on how a reviewer can see the patch working, linked to a built-in test if one exists.

Two maintainers from different roles approve a patch before it enters the catalogue. The full format is described in Patch format.

Review a patch

You do not need commit access to review. Read the diff, apply it to a clean checkout with bep apply --dry-run, and report what you saw. Reviews that mention a concrete command and its output are worth ten that say “looks fine”. The review checklist lives in the repository next to the catalogue.

Office hour

On the first Thursday of each month, one maintainer answers questions in a single issue thread opened for that purpose. Notes are posted in the same thread afterwards, so the discussion stays searchable. The October session ran on 2026-10-01 and its thread stays open for follow-ups.

Code of conduct

Be specific, assume the other person has read less context than you, and do not turn a review into a debate about taste. Harassment, personal attacks and publishing someone's private information end the conversation. Maintainers may lock a thread without further explanation; a locked thread can be reopened by asking in a new issue.

Licence of contributions

Patches and documentation contributed to the project are accepted under MPL-2.0. You keep the copyright on your work. There is no contributor licence agreement to sign; the repository records the provenance of each patch in its header.