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>
96 lines
2.7 KiB
Markdown
96 lines
2.7 KiB
Markdown
# Contributing to Silo
|
|
|
|
Silo welcomes focused contributions that improve security, reliability,
|
|
compatibility, packaging, tests, or maintainability. This repository preserves
|
|
MinIO-compatible interfaces and storage formats, so changes must identify and
|
|
test any compatibility impact.
|
|
|
|
## Development Workflow
|
|
|
|
Fork the current Silo source repository, create a topic branch, and submit a
|
|
pull request. Discuss broad or compatibility-sensitive changes in an issue
|
|
before implementation.
|
|
|
|
### Set up a checkout
|
|
|
|
```sh
|
|
git clone https://github.com/pgsty/minio
|
|
cd minio
|
|
go build -o silo .
|
|
./silo --version
|
|
```
|
|
|
|
The `pgsty/minio` source-repository name is transitional. Follow repository
|
|
redirects after the coordinated `pgsty/silo` cutover.
|
|
|
|
### Keep the lineage remote separate
|
|
|
|
```sh
|
|
git remote add lineage https://github.com/minio/minio
|
|
git fetch lineage
|
|
```
|
|
|
|
Do not merge an upstream branch into a pull request unless the maintainers have
|
|
agreed on the scope. Silo intentionally carries a small downstream delta.
|
|
|
|
### Create your feature branch
|
|
|
|
Create a separate branch before making code changes:
|
|
|
|
```
|
|
git checkout -b my-new-feature
|
|
```
|
|
|
|
### Test Silo server changes
|
|
|
|
Before opening a pull request:
|
|
|
|
- Add or update tests for changed behavior.
|
|
- Run `make verifiers`.
|
|
- Run the smallest relevant package tests, then `make test` when practical.
|
|
- Run `make build` and confirm the generated executable is `silo`.
|
|
- Explain any preserved `MINIO_*`, `minio_*`, `x-minio-*`, `/minio/*`,
|
|
`.minio.sys`, ARN, module/import-path, or serialized compatibility name.
|
|
|
|
### Commit changes
|
|
|
|
After verification, commit your changes with a concise message:
|
|
|
|
```
|
|
git commit -am 'Fix object replication retry handling'
|
|
```
|
|
|
|
### Push to the branch
|
|
|
|
Push your locally committed changes to the remote origin (your fork)
|
|
|
|
```
|
|
git push origin my-new-feature
|
|
```
|
|
|
|
### Create a Pull Request
|
|
|
|
Pull requests should include motivation, reproduction steps where applicable,
|
|
test evidence, compatibility notes, and documentation impact. Public product
|
|
documentation is owned by the separate
|
|
[`pgsty/silo.pgsty.com`](https://github.com/pgsty/silo.pgsty.com) repository.
|
|
|
|
## FAQs
|
|
|
|
### How does Silo manage dependencies?
|
|
|
|
Silo uses Go modules. Preserve the compatibility module and import paths in
|
|
`go.mod`; downstream forks are selected with explicit `replace` directives.
|
|
|
|
- Run `go get foo/bar` in the source folder to add the dependency to `go.mod` file.
|
|
|
|
To remove a dependency
|
|
|
|
- Edit your code and remove the import reference.
|
|
- Run `go mod tidy` in the source folder to remove dependency from `go.mod` file.
|
|
|
|
### What are the coding guidelines?
|
|
|
|
Follow the existing Go style, run `gofmt` on changed Go files, and keep changes
|
|
compact. See the Go project's [code review comments](https://go.dev/wiki/CodeReviewComments).
|