change README, ROADMAP to point to discourse forum. add other mds

CONTRIBUTING.md

@@ -0,0 +1,173 @@
+# Contributing to Rotonda
+
+Hi! Thank you for wanting to contribute to Rotonda.
+
+This document offers guidelines on how best to contribute. Following the
+guidelines here give your contributions the best chance at getting merged.
+
+## Code of Conduct
+
+This project and everyone participating in it is governed by the [NLnet Labs
+Code of Conduct]. By participating, you are expected to uphold this code.
+
+## A note on Generative AI
+
+We do not accept any content -- code, documentation or otherwise -- generated
+by large language models or other generative AI.
+
+## Discussion
+
+### Asking questions
+
+The best place to ask questions is on [Discourse]. Please look through
+existing posts before creating a new thread.
+
+### Reporting security vulnerabilities
+
+See [SECURITY.md].
+
+### Reporting other bugs
+
+If you find something that is clearly a bug, you can submit it directly to the
+issue tracker. Please look though existing issues before creating a new issue.
+You should also check whether your issue has already been addressed on the
+`main` branch.
+
+Try to include as much as possible of the following information:
+
+ - Version/branch/commit of Rotonda you are using
+ - Your system (OS, architecture)
+ - Any stack traces or logging messages
+ - A reproducer that shows the issue
+
+### Suggesting enhancements
+
+If you have ideas for improving Rotonda, you can start a discussion about it
+on [Discourse]. Please look through other posts to see whether your idea has
+been discussed before.
+
+Be sure to include clear use-cases and motivation for your idea.
+
+## Contribution
+
+### License and copyright
+
+When contributing with code or other content, you agree to put your changes
+and new code under the same license Rotonda and its associated libraries is
+already using. When changing existing source code, do not alter the copyright
+of the original file(s). The copyright will still be owned by the original
+creator(s) or those who have been assigned copyright by the original
+author(s).
+
+By submitting a patch to Rotonda, you are assumed to have the right to
+the code and to be allowed by your employer or whatever to hand over that
+patch/code to us. We will credit you for your changes as far as possible, to
+give credit but also to keep a trace back to who made what changes.
+
+### Contributing documentation
+
+Writing documentation is very hard, but _very_ appreciated. Improving
+the documentation could mean anything from adding new chapters to
+fixing a typo. The documentation of Rotonda has a repository of its
+[own](https://github.com/nlnetLabs/rotonda-doc).
+
+ - Go to the `/manual/docs/` folder of this repository.
+
+The documentation in the `/manual/docs/` folder is written in
+[reStructuredText] and hosted [ReadTheDocs] via [Sphinx]. If you have the [uv]
+tool installed, you can easily build the documentation locally with
+
+```
+make html
+```
+
+You can then serve those files however you want, for example using
+
+```
+python -m http.server
+```
+
+You can submit your changes in a pull request. A preview version of the updated
+documentation will be built automatically for your PR. You can view it by
+clicking on the ReadTheDocs action on the PR page or by visiting
+
+```
+https://rotonda--XXX.org.readthedocs.build/
+```
+
+where `XXX` is the number of your PR.
+
+### Contributing code
+
+Before you start contributing code, ensure that the issue you are tackling has
+been properly discussed either on [Discourse] or the [issue tracker]. Do not
+submit pull requests for changes that have not been discussed.
+
+You can contribute code by opening a pull request against the branch called
+`dev`. Opening a PR against any other branch will have to be rebased to `dev`.
+Before you do you should check that you code passes all tests and adheres to
+the [style guide](#style-guide). You do not have to update `Changelog.md`.
+That will be updated when a release is tagged.
+
+You run the code, you'll need to have a working and recent enough Rust
+toolchain installed. The [just] tool can also come in handy to run some common
+commands on this repository.
+
+Keep the following in mind while submitting your code:
+
+ - Work on a branch of your own created branched of the branch called `dev` in
+   our repository.
+ - Start the name of your branch with `feature-` or `bugfix-` or another
+   small functional description. Add a small description of the content of
+   the changes/additions, e.g. 'tcp-ao', so the full branch name would be
+   `feature-tcp-ao`.
+ - Make sure to link the appropriate issue for your change. If there is none,
+   make the issue and discuss the change before submitting the PR.
+ - Use descriptive commit messages.
+ - Your code can only be merged once the CI is green.
+ - Keep your PRs self-contained and do not include unrelated changes. It's
+   better to submit many small PRs than one big PR with multiple changes.
+
+See [TESTING.md] for information on how to test your changes.
+
+### Style guide
+
+We follow standard style guides for Rust code. That is, we require that the
+code is formatted by `rustfmt` and that it passes the checks of the latest
+version of the `clippy` linter. The code should also be free of warnings
+generated by `rustc`.
+
+Rotonda tries to minimize on `unsafe` code. This is not to say that we don't
+rely on `unsafe` code, but we are trying to isolate it in separate crates as
+much as possible, i.e. the `routedb` crate. If you really must use `unsafe`
+code, we require that Valgrind does not raise any issues on test suite. Each
+`unsafe` block be accompanied by a `SAFETY` comment and each `unsafe` function
+should have a "Safety" section in its documentation. We generally do not rely
+on `unsafe` just to achieve better performance.
+
+## Maintainance
+
+This section is meant for maintainers of Rotonda, not for all contributors.
+
+### Dependencies
+
+Be careful pulling in new dependencies. We should not pull in large
+dependencies for small gains. The license should also be compatible with
+Rotonda's license. You can use `cargo deny` to check that.
+
+### Releases
+
+The steps for releasing a new version of Rotonda are described in RELEASING.md
+in the root of this repository.
+
+[NLnet Labs Code of Conduct]: https://www.nlnetlabs.nl/conduct
+[Discourse]: https://community.nlnetlabs.nl/c/rotonda/5
+[issue tracker]: https://github.com/rotonda/NLnetLabs/issues
+[reStructuredText]: http://www.sphinx-doc.org/en/stable/rest.html
+[ReadTheDocs]: https://readthedocs.org/
+[Sphinx]: http://www.sphinx-doc.org
+[uv]: https://docs.astral.sh/uv/
+[just]: https://just.systems/man/en/
+[SemVer]: https://semver.org/
+[SECURITY.md]: ./SECURITY.md
+[TESTING.md]: ./TESTING.md

README.md

@@ -24,7 +24,13 @@ install and use Rotonda.
 > 0.x versions.
 >
 > For more information on upcoming features and changes see the 
-> [ROADMAP](ROADMAP.md)
+> [roadmap](https://community.nlnetlabs.nl/t/rotonda-roadmap-for-2026/34/5).
+
+Go to the [community forum](https://community.nlnetlabs.nl/c/rotonda/5) to
+get support from the community, exchange experiences, open issues, and more.
+
+Rather than opening issues on GitHub we encourage you to open topics on our
+forum.
 
 ## GOALS
 

RELEASING.md

@@ -0,0 +1,65 @@
+Rotonda RC and Final Release
+
+For a final release the workflow is the same as for an RC. Just leave out the
+`-rcXX` everywhere it is mentioned.
+
+A. CREATE RELEASE BRANCH
+
+  * create release branch with name release-x.y.0-rcz, e.g. release-0.1.0-rc0.
+    Note: we start counting at ZERO for the rc, and there's no '.' or '-' in
+    between rc and the number.
+  * Update [package] version field in Cargo.toml (e.g. version = "0.1.0-rc0").
+  * Finalize Changelog.md:
+  * Add release date in the form "Released yyyy-mm-dd.". Note the dot at the
+    end.
+  * Remove unused sections.
+  * Review & update dependencies in `Cargo.toml`.
+  * Run `cargo update`
+  * If the previous step actually updated any crates, run `cargo check
+    --all-features --tests --release --examples`. If there are any warnings
+    and/or errors, fix them and go back to step A.4.
+  * [library only] Run cargo +nightly test -Z minimal-versions --release
+    --all-features. If there are any warnings and/or errors, fix them and go
+    back to step A.4.
+  * Add and commit changes to this release branch.
+  * Run `cargo package`. This will try building the crate locally, and will
+    output warnings and/or errors. If there are any, fix those, and add &
+    commit these fixes. Run cargo package again to see if they are actually
+    fixed.
+  * Push changes to GitHub (e.g. `git push --set-upstream origin release-0.1.i
+    0-rc0`).
+
+
+B. CREATE PULL REQUEST
+
+  * Create pull request on GitHub main ← release-x.y.0-rcz and wait for CI
+    to finish.
+  * Merge pull request. Add the changes for the release from Changelog.md as
+    the commit message body (the GitHub web UI lets you do this).
+
+
+C. TAG ON BRANCH MAIN AND RELEASE PACKAGE
+
+  * Check out branch `main` and pull
+  * Double-check `Cargo.toml` and `Changelog.md`.
+  * Run `cargo publish`
+  * Create and push release tag with tag of form vx.y.0-rcz, e.g. `git tag -a
+    v0.1.0-rc0`.
+  * Add the changes for the release from Changelog.md as the tag message body
+    (Same as the merge commit message from the previous PR).
+  * Push the tag to GitHub (e.g. `git push --tags`).
+  * [Application Only] Create a release on GitHub.
+
+
+D. CREATE POST RELEASE COMMIT
+
+  * Still in branch `main`. Add new section to `Changelog.md` called
+    Unreleased new version.
+  * `Cargo.toml`: Increase version.
+  * [Application Only] Cargo.lock: Run cargo update -p <APPLICATION_NAME>,
+    e.g. `cargo update -p rotonda`
+
+
+E. CREATE PACKAGES ON PACKAGES.NLNETLABS.NL
+
+  (not described here)

ROADMAP.md

@@ -2,86 +2,4 @@
 Roadmap
 =======
 
-- ✅ work item complete
-- 🦀 work item in progress
-- 💤 work item not started yet
-
-
-## `Rotonda`
-
-### 0.3: Collector functionality
-
-- 💤 Provide passive external data sources to Roto, specifically with Routinator.
-- 💤 On-disk storage to prevent growing memory use
-- 💤 More ingress connectors (e.g. Kafka, mrt (finalise), rtr)
-
-### LATER RELEASES
-
-- 💤 Switch to daemon-base
-- 💤 Store other AFI/SAFI types than unicast & multicast
-- 💤 CLI for querying RIBs
-- 💤 Emit BGP packets as events on OutputStream
-- 💤 Egress modified/created BGP packets (on peering sessions)
-- 💤 Refactor configuration: dynamic units reconfiguration with RESTCONF/yang+json
-- 💤 More egress connectors (e.g. Kafka, Parquet, mrt, (timescale) RDBMS)
-- 💤 BMP & BGP proxy
-- 💤 BMP out stream
-- 💤 Long-term file storage
-- 💤 Create experimental global registry
-- 💤 Snapshot/restore functionality
-- 💤 RIB diff functionality
-- 💤 Create experimental distributed Rotondas (Sharding)
-
-
-## `Roto language`
-
-### NEXT RELEASE 0.4
-
-- 🦀 Create dev documentation
-- 🦀 Create reference-level documentation
-- 💤 accomodate querying RIBs as external data source
-- 💤 Schemas and dynamic types in Roto functions
-- 💤 Global variables
-- 💤 Create namespaces / modules system
-
-### LATER RELEASES
-
-- 💤 implement more passive external data sources
-- 💤 create user-configurable graph DSL for units
-- 💤 create user-configurable query DSL
-
-
-## `Routecore`
-
-### NEXT RELEASE 0.6
-
-- 💤 Optimizations
-
-### LATER RELEASES
-
-- 💤 BGPsec parser
-- 💤 More AFI/SAFI types
-- 💤 Move BMP FSM from Rotonda to Routecore
-- 💤 Refactor BGP FSM with BoQ in mind
-- 💤 Type-aware wire format path attributes
-
-
-## `Rotonda-store`
-
-### NEXT RELEASE 0.5
-
-- 🦀 On-disk storage integration
-- 🦀 Optimizations: better hashing, cache padding, etc.
-
-### LATER RELEASES
-
-- 💤 Query Plans
-- 💤 Indexing (dynamic and static)
-
-## `Rotoro`
-
-### MVP
-
-- 🦀 Design wire protocol and select a layout (AVRO?)
-- 💤 Create experimental de/serialization
-- 💤 Experimental integration in `rotonda`
+The roadmap can be found [here](https://community.nlnetlabs.nl/t/rotonda-roadmap-for-2026/34/5).

TESTING.md

@@ -0,0 +1,53 @@
+# Testing
+
+The tests of Rotonda live in a few places:
+
+ - the `/tests`
+ - unit tests in the source code
+ - doctests in the source code
+
+Running these tests is done with a single command:
+```
+cargo test --all-features --release
+```
+
+Use with `cargo nextest` is probably possible, but, well, untested.
+
+## Snapshot testing
+
+Some of the tests use snapshot testing using [insta]. You can run
+them with the regular Rust test runner, but to change them, you might want to
+install `cargo-insta` with `cargo install cargo-insta`. See the [insta] website for more information.
+
+## Valgrind
+
+If you want to submit `unsafe` code to Rotonda, we require that the entire
+test suite is run under [Valgrind]. To do that locally, you'll need to install
+Valgrind and `cargo-valgrind`.
+
+If you have [just] installed, you can run the test suite under valgrind with
+
+```
+just valgrind
+```
+
+But you can also use the full expression without [just] if you prefer:
+
+```
+VALGRINDFLAGS="--suppressions=valgrind_suppressions.supp" cargo valgrind test --all-targets
+```
+
+## MIRI
+
+A subset of tests is also run under MIRI, which is even more strict than
+Valgrind, but also cannot run all tests.
+
+You can run the relevant tests under MIRI with:
+
+```
+MIRIFLAGS=-Zmiri-disable-isolation cargo +nightly miri test
+```
+
+[insta]: https://insta.rs/
+[Valgrind]: https://valgrind.org/
+[just]: https://just.systems/man/en/