Contributing: Difference between revisions
No edit summary |
Wikiservice (talk | contribs) (Refresh MemCP documentation: accuracy, operational guidance, performance profile and maintained API reference) |
||
| Line 1: | Line 1: | ||
<!-- Copyright (C) 2026 Carl-Philip Haensch --> | |||
<!-- SPDX-License-Identifier: GPL-3.0-or-later --> | |||
= Contributing = | |||
MemCP welcomes focused contributions to the storage engine, Scheme runtime, SQL frontends, query planner, tests, documentation, packaging, and operational tooling. A useful change starts with an observable problem or clearly bounded feature, explains its semantic and performance impact, and includes evidence that existing behavior remains intact. | |||
Current work is tracked in the [https://github.com/launix-de/memcp/issues GitHub issue tracker]. Discuss large semantic, persistence-format, planner-architecture, or compatibility changes before implementation so the design and required migration path are understood. Documentation fixes should preserve valuable historical explanations while clearly separating current behavior, measured results, and future architecture. | |||
== Development workflow == | |||
# Fork or clone the repository. | |||
# Create a dedicated branch and worktree for one change. | |||
# Add successful and must-fail tests for every behavior change. | |||
# Run <code>make test</code> before pushing code or test changes. | |||
# Open a pull request against <code>master</code> and wait for green CI. | |||
SQL integration tests are YAML files below <code>tests/</code>; Scheme runtime tests live in <code>lib/test.scm</code>. Planner work must follow <code>INVARIANTS.md</code> and keep logical planning separate from physical scans, RecSets, ORC columns, and helper tables. Storage changes must preserve locking, durability, cleanup, and binary-format compatibility contracts documented in <code>AGENTS.md</code> and the engine semantics documentation. | |||
Do not use the wiki as a TODO tracker. A report should include the MemCP commit, minimal schema/query, expected and actual result, frontend, ENGINE, and restart behavior. | |||
Latest revision as of 11:59, 28 August 2026
Contributing
MemCP welcomes focused contributions to the storage engine, Scheme runtime, SQL frontends, query planner, tests, documentation, packaging, and operational tooling. A useful change starts with an observable problem or clearly bounded feature, explains its semantic and performance impact, and includes evidence that existing behavior remains intact.
Current work is tracked in the GitHub issue tracker. Discuss large semantic, persistence-format, planner-architecture, or compatibility changes before implementation so the design and required migration path are understood. Documentation fixes should preserve valuable historical explanations while clearly separating current behavior, measured results, and future architecture.
Development workflow
- Fork or clone the repository.
- Create a dedicated branch and worktree for one change.
- Add successful and must-fail tests for every behavior change.
- Run
make testbefore pushing code or test changes. - Open a pull request against
masterand wait for green CI.
SQL integration tests are YAML files below tests/; Scheme runtime tests live in lib/test.scm. Planner work must follow INVARIANTS.md and keep logical planning separate from physical scans, RecSets, ORC columns, and helper tables. Storage changes must preserve locking, durability, cleanup, and binary-format compatibility contracts documented in AGENTS.md and the engine semantics documentation.
Do not use the wiki as a TODO tracker. A report should include the MemCP commit, minimal schema/query, expected and actual result, frontend, ENGINE, and restart behavior.