|
| 1 | +# Contributing to Rust Service Mesh |
| 2 | + |
| 3 | +Thank you for your interest in contributing to Rust Service Mesh! This document provides guidelines for contributing to the project. |
| 4 | + |
| 5 | +## Code of Conduct |
| 6 | + |
| 7 | +Be respectful, inclusive, and professional. We're all here to build great software together. |
| 8 | + |
| 9 | +## Getting Started |
| 10 | + |
| 11 | +1. **Fork the repository** on GitHub |
| 12 | +2. **Clone your fork** locally: |
| 13 | + ```bash |
| 14 | + git clone https://github.com/YOUR_USERNAME/Rust-ServiceMesh.git |
| 15 | + cd Rust-ServiceMesh |
| 16 | + ``` |
| 17 | +3. **Create a branch** for your changes: |
| 18 | + ```bash |
| 19 | + git checkout -b feature/my-awesome-feature |
| 20 | + ``` |
| 21 | + |
| 22 | +## Development Workflow |
| 23 | + |
| 24 | +### Prerequisites |
| 25 | + |
| 26 | +- Rust 1.75 or later |
| 27 | +- Cargo |
| 28 | +- Git |
| 29 | + |
| 30 | +### Building |
| 31 | + |
| 32 | +```bash |
| 33 | +# Debug build |
| 34 | +cargo build |
| 35 | + |
| 36 | +# Release build |
| 37 | +cargo build --release |
| 38 | +``` |
| 39 | + |
| 40 | +### Testing |
| 41 | + |
| 42 | +All contributions must include tests and pass existing tests: |
| 43 | + |
| 44 | +```bash |
| 45 | +# Run all tests |
| 46 | +cargo test |
| 47 | + |
| 48 | +# Run tests for a specific module |
| 49 | +cargo test circuit_breaker |
| 50 | + |
| 51 | +# Run with logging |
| 52 | +RUST_LOG=debug cargo test |
| 53 | + |
| 54 | +# Run clippy (required) |
| 55 | +cargo clippy --all-features -- -D warnings |
| 56 | + |
| 57 | +# Format code (required) |
| 58 | +cargo fmt |
| 59 | +``` |
| 60 | + |
| 61 | +### Code Quality Standards |
| 62 | + |
| 63 | +#### Rust Style |
| 64 | +- Follow standard Rust conventions (enforced by `rustfmt`) |
| 65 | +- Run `cargo fmt` before committing |
| 66 | +- All code must pass `cargo clippy --all-features -- -D warnings` |
| 67 | +- Use meaningful variable and function names |
| 68 | +- Keep functions under 100 lines when possible |
| 69 | + |
| 70 | +#### Documentation |
| 71 | +- Add `///` doc comments to all public items |
| 72 | +- Include examples in doc comments for complex APIs |
| 73 | +- Update README.md if adding user-facing features |
| 74 | +- Doc tests should compile (`cargo test --doc`) |
| 75 | + |
| 76 | +#### Error Handling |
| 77 | +- Use `Result` types, avoid panics in library code |
| 78 | +- Provide context in error messages |
| 79 | +- Use `thiserror` for error types |
| 80 | + |
| 81 | +#### Testing |
| 82 | +- Write unit tests for all new functionality |
| 83 | +- Add integration tests for end-to-end scenarios |
| 84 | +- Aim for >80% code coverage |
| 85 | +- Test error paths, not just happy paths |
| 86 | + |
| 87 | +#### Performance |
| 88 | +- Profile performance-critical code |
| 89 | +- Avoid unnecessary allocations |
| 90 | +- Use `Arc` for shared state, avoid `Mutex` when possible |
| 91 | +- Prefer lock-free atomics for counters |
| 92 | + |
| 93 | +## Pull Request Process |
| 94 | + |
| 95 | +1. **Ensure your code passes all checks**: |
| 96 | + ```bash |
| 97 | + cargo fmt --check |
| 98 | + cargo clippy --all-features -- -D warnings |
| 99 | + cargo test --all |
| 100 | + cargo build --release |
| 101 | + ``` |
| 102 | + |
| 103 | +2. **Update documentation**: |
| 104 | + - Add/update doc comments |
| 105 | + - Update README.md if needed |
| 106 | + - Add examples if introducing new features |
| 107 | + |
| 108 | +3. **Write a clear PR description**: |
| 109 | + - Explain what changes you made and why |
| 110 | + - Reference any related issues |
| 111 | + - Include before/after behavior if applicable |
| 112 | + |
| 113 | +4. **Commit message format**: |
| 114 | + ``` |
| 115 | + type: brief description |
| 116 | +
|
| 117 | + Longer explanation if needed. |
| 118 | +
|
| 119 | + Fixes #123 |
| 120 | + ``` |
| 121 | + |
| 122 | + Types: `feat`, `fix`, `docs`, `refactor`, `test`, `perf`, `chore` |
| 123 | + |
| 124 | +5. **Submit the PR**: |
| 125 | + - Push to your fork |
| 126 | + - Open a PR against `main` |
| 127 | + - Respond to review feedback |
| 128 | + |
| 129 | +## Areas for Contribution |
| 130 | + |
| 131 | +### High Priority |
| 132 | +- [ ] Retry logic with exponential backoff |
| 133 | +- [ ] Connection pooling in Transport module |
| 134 | +- [ ] Rate limiting middleware |
| 135 | +- [ ] Health checking for upstreams |
| 136 | +- [ ] Additional integration tests |
| 137 | + |
| 138 | +### Medium Priority |
| 139 | +- [ ] Distributed tracing (OpenTelemetry) |
| 140 | +- [ ] Advanced load balancing algorithms |
| 141 | +- [ ] L7 routing implementation |
| 142 | +- [ ] HTTP/2 support |
| 143 | +- [ ] Benchmarking suite |
| 144 | + |
| 145 | +### Low Priority |
| 146 | +- [ ] mTLS support |
| 147 | +- [ ] gRPC proxying |
| 148 | +- [ ] WASM filter support |
| 149 | +- [ ] Kubernetes sidecar mode |
| 150 | + |
| 151 | +## Architecture Guidelines |
| 152 | + |
| 153 | +### Module Organization |
| 154 | +- Keep modules focused and single-purpose |
| 155 | +- Use `pub(crate)` for internal APIs |
| 156 | +- Expose minimal public surface area |
| 157 | +- Group related functionality |
| 158 | + |
| 159 | +### Async/Await |
| 160 | +- Use Tokio for async runtime |
| 161 | +- Avoid blocking operations in async contexts |
| 162 | +- Use `tokio::spawn` for CPU-intensive work |
| 163 | +- Prefer `tokio::select!` over manual polling |
| 164 | + |
| 165 | +### Dependencies |
| 166 | +- Justify new dependencies in your PR |
| 167 | +- Prefer well-maintained crates |
| 168 | +- Check licenses (Apache-2.0 or MIT compatible) |
| 169 | +- Run `cargo audit` to check for vulnerabilities |
| 170 | + |
| 171 | +### Error Handling |
| 172 | +```rust |
| 173 | +// Good: Contextual errors |
| 174 | +.map_err(|e| ProxyError::ListenerBind { |
| 175 | + addr: addr.to_string(), |
| 176 | + source: e, |
| 177 | +})? |
| 178 | + |
| 179 | +// Bad: Generic errors |
| 180 | +.map_err(|e| format!("Error: {}", e))? |
| 181 | +``` |
| 182 | + |
| 183 | +### Logging |
| 184 | +```rust |
| 185 | +// Use tracing macros |
| 186 | +use tracing::{debug, info, warn, error, instrument}; |
| 187 | + |
| 188 | +#[instrument(level = "debug", skip(self))] |
| 189 | +async fn my_function(&self) { |
| 190 | + info!("Starting operation"); |
| 191 | + debug!(param = ?value, "Processing"); |
| 192 | +} |
| 193 | +``` |
| 194 | + |
| 195 | +## Questions? |
| 196 | + |
| 197 | +- Open an issue for bugs or feature requests |
| 198 | +- Start a discussion for design questions |
| 199 | +- Check existing issues before creating new ones |
| 200 | + |
| 201 | +## License |
| 202 | + |
| 203 | +By contributing, you agree that your contributions will be dual-licensed under both the MIT License and Apache License 2.0, at the user's option. |
| 204 | + |
| 205 | +--- |
| 206 | + |
| 207 | +Thank you for contributing to Rust Service Mesh! |
0 commit comments