mirror of
https://github.com/pgsty/minio.git
synced 2026-08-09 15:53:28 +03:00
Feng Ruohang
fd2ca1c6d2
README, README_ZH, SECURITY, COMPLIANCE, CONTRIBUTING, NOTICE, code_of_conduct, the vulnerability and PR-etiquette documents, the GitHub issue and pull request templates, and the docs/ tree all present Silo as the product. The Grafana dashboards under docs/metrics/prometheus/grafana/ have their panel titles and descriptions rebranded while every minio_* query, label and expression is left alone, so existing alerts and recording rules keep matching. The distinction the review demanded is applied per hit rather than by search-and-replace: - Product and command text becomes Silo and silo: install and run instructions, systemd examples, compose services, download links, badges. - Protocol and interface text keeps MinIO: MINIO_* variables, minio_* metrics, x-minio-* headers, /minio/* routes, .minio.sys, arn:minio, and API field and error names. - Attribution keeps MinIO and gains the fork's own: the AGPL obligations, original copyright, CREDITS and NOTICE stay, with the modification notice added alongside rather than replacing them. - Historical and third-party references are left as facts, not rewritten for brand tidiness. README and README_ZH each carry an explicit non-affiliation notice, document the side-by-side package migration including the /etc/systemd/system/silo.service.d/10-legacy-user.conf drop-in for keeping a legacy UID/GID, and state that recursive chown is never performed. The trademark attribution uses the policy's approved "based on MinIO technology" wording, not the shortened form the policy rejects. github.com/pgsty/minio links are left in place and labelled transitional. The repository has not been renamed, and rewriting them now would produce documented URLs that 404 until the cutover; they change in the cutover commit together with the goreleaser release target, the OCI source label and the raw-content branch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
94 lines
4.6 KiB
Markdown
94 lines
4.6 KiB
Markdown
# Silo Pull Request Guidelines
|
||
|
||
These guidelines ensure high-quality commits in Silo's GitHub repositories, maintaining
|
||
a clear, valuable commit history for our open-source projects. They apply to all contributors,
|
||
fostering efficient reviews and robust code.
|
||
|
||
## Why Pull Requests?
|
||
|
||
Pull Requests (PRs) drive quality in Silo's codebase by:
|
||
- Enabling peer review without pair programming.
|
||
- Documenting changes for future reference.
|
||
- Ensuring commits tell a clear story of development.
|
||
|
||
**A poor commit lasts forever, even if code is refactored.**
|
||
|
||
## Crafting a Quality PR
|
||
|
||
A strong Silo PR:
|
||
- Delivers a complete, valuable change (feature, bug fix, or improvement).
|
||
- Has a concise title (e.g., `[S3] Fix bucket policy parsing #1234`) and a summary with context, referencing issues (e.g., `#1234`).
|
||
- Contains well-written, logical commits explaining *why* changes were made (e.g., “Add S3 bucket tagging support so that users can organize resources efficiently”).
|
||
- Is small, focused, and easy to review—ideally one commit, unless multiple commits better narrate complex work.
|
||
- Adheres to Silo's coding standards (e.g., Go style, error handling, testing).
|
||
|
||
PRs must flow smoothly through review to reach production. Large PRs should be split into smaller, manageable ones.
|
||
|
||
## Submitting PRs
|
||
|
||
1. **Title and Summary**:
|
||
- Use a scannable title: `[Subsystem] Action Description #Issue` (e.g., `[IAM] Add role-based access control #567`).
|
||
- Include context in the summary: what changed, why, and any issue references.
|
||
- Use `[WIP]` for in-progress PRs to avoid premature merging or choose GitHub draft PRs.
|
||
|
||
2. **Commits**:
|
||
- Write clear messages: what changed and why (e.g., “Refactor S3 API handler to reduce latency so that requests process 20% faster”).
|
||
- Rebase to tidy commits before submitting (e.g., `git rebase -i main` to squash typos or reword messages), unless multiple contributors worked on the branch.
|
||
- Keep PRs focused—one feature or fix. Split large changes into multiple PRs.
|
||
|
||
3. **Testing**:
|
||
- Include unit tests for new functionality or bug fixes.
|
||
- Ensure existing tests pass (`make test`).
|
||
- Document testing steps in the PR summary if manual testing was performed.
|
||
|
||
4. **Before Submitting**:
|
||
- Run `make verify` to check formatting, linting, and tests.
|
||
- Reference related issues (e.g., “Closes #1234”).
|
||
- Notify team members via GitHub `@mentions` if urgent or complex.
|
||
|
||
## Reviewing PRs
|
||
|
||
Reviewers ensure Silo's commit history remains a clear, reliable record. Responsibilities include:
|
||
|
||
1. **Commit Quality**:
|
||
- Verify each commit explains *why* the change was made (e.g., “So that…”).
|
||
- Request rebasing if commits are unclear, redundant, or lack context (e.g., “Please squash typo fixes into the parent commit”).
|
||
|
||
2. **Code Quality**:
|
||
- Check adherence to Silo's Go standards (e.g., error handling, documentation).
|
||
- Ensure tests cover new code and pass CI.
|
||
- Flag bugs or critical issues for immediate fixes; suggest non-blocking improvements as follow-up issues.
|
||
|
||
3. **Flow**:
|
||
- Review promptly to avoid blocking progress.
|
||
- Balance quality and speed—minor issues can be addressed later via issues, not PR blocks.
|
||
- If unable to complete the review, tag another reviewer (e.g., `@username please take over`).
|
||
|
||
4. **Shared Responsibility**:
|
||
- All Silo contributors are reviewers. The first commenter on a PR owns the review unless they delegate.
|
||
- Multiple reviewers are encouraged for complex PRs.
|
||
|
||
5. **No Self-Edits**:
|
||
- Don’t modify the PR directly (e.g., fixing bugs). Request changes from the submitter or create a follow-up PR.
|
||
- If you edit, you’re a collaborator, not a reviewer, and cannot merge.
|
||
|
||
6. **Testing**:
|
||
- Assume the submitter tested the code. If testing is unclear, ask for details (e.g., “How was this tested?”).
|
||
- Reject untested PRs unless testing is infeasible, then assist with test setup.
|
||
|
||
## Tips for Success
|
||
|
||
- **Small PRs**: Easier to review, faster to merge. Split large changes logically.
|
||
- **Clear Commits**: Use `git rebase -i` to refine history before submitting.
|
||
- **Engage Early**: Discuss complex changes in a GitHub issue before coding.
|
||
- **Be Responsive**: Address reviewer feedback promptly to keep PRs moving.
|
||
- **Learn from Reviews**: Use feedback to improve future contributions.
|
||
|
||
## Resources
|
||
|
||
- [Silo Contribution Guide](CONTRIBUTING.md)
|
||
- [Effective Commit Messages](https://mislav.net/2014/02/hidden-documentation/)
|
||
- [GitHub PR Tips](https://github.com/blog/1943-how-to-write-the-perfect-pull-request)
|
||
|
||
By following these guidelines, we ensure Silo's codebase remains high-quality, maintainable, and a joy to contribute to. Happy coding!
|