jcoffey-dev
a63839f6b0
SPEC 2.2a says INBUXA writes its own when the repository is first published, and it is. Until now the public repository carried Stalwart's: a security policy telling people to report vulnerabilities to Stalwart Labs, and a contributing guide whose policy is that pull requests from anyone not on upstream's vouched list are closed automatically. Neither is this project's, and both were being offered to anyone who looked. So: a security policy that says where to send a report, and what happens if it turns out to be upstream's bug rather than ours; a contributing guide that says what a fork of someone else's code needs from a contributor, including the clean-room question, since the record has to stay true; the Contributor Covenant; and a sponsor link. Upstream's two security documents move to .github-upstream/ beside its workflows -- kept, not used, not presented as ours. CI builds the server and compiles every test target, and deliberately runs no suite. The unit tests only build with the integration crate in the graph, and the integration suites want a STORE, fixed ports and a container apiece, so running them here would mean a tick that skipped everything or a cross that means "the runner has no Redis". The workflow says as much, so nobody has to rediscover it. Also ignores /artifact: two hand-built binaries, ~190 MB, one `git add -A` away from a public repository.
2.5 KiB
Contributing
Patches, bug reports and questions are welcome.
Before a pull request
Open an issue first for anything substantial. A feature or a refactor is worth agreeing on before it is written, because this is a fork that tracks upstream: a change that moves code around costs a conflict on every import, and it should be worth that.
Small fixes — a bug, a typo, a test — need no ceremony. Send them.
What this repository is
INBUXA is a fork of Stalwart, taken under the AGPL-3.0-only half of its dual licence, with nine features rebuilt independently. Two things follow:
- The clean room is real. The rebuilt features in
crates/featureswere written from specifications indocs/spec/features/, by people who had not read Stalwart's Enterprise source. If you have read it, say so in the pull request and it will be reviewed with that in mind, or declined for the parts it touches. Nothing about this is personal: the project's defence of independent creation is a record, and the record has to be true. - Upstream files stay recognisable. Changes to files that came from
upstream are kept small and marked with an
inbuxa:comment saying which requirement they serve, so the next import merges cleanly and a reader can tell fork from base. New work belongs in the fork's own crates where it can.
Licence and provenance
Contributions are under AGPL-3.0-only. Keep upstream's copyright headers where they are; if you change a file that came from upstream, leave its "Modified by Coffey Labs" line in place. New files carry:
/*
* SPDX-FileCopyrightText: 2026 Coffey Labs
*
* SPDX-License-Identifier: AGPL-3.0-only
*/
If you bring in code from another project, it stays under its own licence and
its notice goes in THIRD-PARTY.md. tools/fork/strip.py reports any file
that is missing from there on every import.
Running the tests
cargo test -p tests runs what needs nothing but a store on disk. The rest
need containers, a particular backend, or a copy of real data, and are
#[ignore]d:
docs/spec/container-tests.md— the suites that need containers, with theSTOREeach one wants and what a plain regression leaves failing.docs/spec/compat-tests.md— the compatibility set, which needs a copy of a real server's data.
Run one suite at a time. They bind fixed ports, and the timing checks flake if two run at once.
Commit messages
Say what changed and why, in prose, wrapped at 72 characters or so. The why is the part that is hard to recover later. No tool trailers.