mirror of
https://github.com/pgsty/minio.git
synced 2026-08-09 15:53:28 +03:00
docs: rebrand the repository documentation, templates and dashboards
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>
This commit is contained in:
Feng Ruohang
+42
-29
@@ -1,55 +1,63 @@
|
||||
# MinIO Contribution Guide [](https://slack.min.io) [](https://hub.docker.com/r/minio/minio/)
|
||||
# Contributing to Silo
|
||||
|
||||
``MinIO`` community welcomes your contribution. To make the process as seamless as possible, we recommend you read this contribution guide.
|
||||
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
|
||||
|
||||
Start by forking the MinIO GitHub repository, make changes in a branch and then send a pull request. We encourage pull requests to discuss code changes. Here are the steps in details:
|
||||
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.
|
||||
|
||||
### Setup your MinIO GitHub Repository
|
||||
|
||||
Fork [MinIO upstream](https://github.com/minio/minio/fork) source repository to your own personal repository. Copy the URL of your MinIO fork (you will need it for the `git clone` command below).
|
||||
### Set up a checkout
|
||||
|
||||
```sh
|
||||
git clone https://github.com/minio/minio
|
||||
git clone https://github.com/pgsty/minio
|
||||
cd minio
|
||||
go install -v
|
||||
ls $(go env GOPATH)/bin/minio
|
||||
go build -o silo .
|
||||
./silo --version
|
||||
```
|
||||
|
||||
### Set up git remote as ``upstream``
|
||||
The `pgsty/minio` source-repository name is transitional. Follow repository
|
||||
redirects after the coordinated `pgsty/silo` cutover.
|
||||
|
||||
### Keep the lineage remote separate
|
||||
|
||||
```sh
|
||||
$ cd minio
|
||||
$ git remote add upstream https://github.com/minio/minio
|
||||
$ git fetch upstream
|
||||
$ git merge upstream/master
|
||||
...
|
||||
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
|
||||
|
||||
Before making code changes, make sure you create a separate branch for these changes
|
||||
Create a separate branch before making code changes:
|
||||
|
||||
```
|
||||
git checkout -b my-new-feature
|
||||
```
|
||||
|
||||
### Test MinIO server changes
|
||||
### Test Silo server changes
|
||||
|
||||
After your code changes, make sure
|
||||
Before opening a pull request:
|
||||
|
||||
- To add test cases for the new code. If you have questions about how to do it, please ask on our [Slack](https://slack.min.io) channel.
|
||||
- To run `make verifiers`
|
||||
- To squash your commits into a single commit. `git rebase -i`. It's okay to force update your pull request.
|
||||
- To run `make test` and `make build` completes.
|
||||
- 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. This is a [great post](https://chris.beams.io/posts/git-commit/) on how to write useful commit messages
|
||||
After verification, commit your changes with a concise message:
|
||||
|
||||
```
|
||||
git commit -am 'Add some feature'
|
||||
git commit -am 'Fix object replication retry handling'
|
||||
```
|
||||
|
||||
### Push to the branch
|
||||
@@ -62,13 +70,17 @@ git push origin my-new-feature
|
||||
|
||||
### Create a Pull Request
|
||||
|
||||
Pull requests can be created via GitHub. Refer to [this document](https://help.github.com/articles/creating-a-pull-request/) for detailed steps on how to create a pull request. After a Pull Request gets peer reviewed and approved, it will be merged.
|
||||
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 ``MinIO`` manage dependencies?
|
||||
### How does Silo manage dependencies?
|
||||
|
||||
``MinIO`` uses `go mod` to manage its 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.
|
||||
|
||||
@@ -77,6 +89,7 @@ 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 for MinIO?
|
||||
### What are the coding guidelines?
|
||||
|
||||
``MinIO`` is fully conformant with Golang style. Refer: [Effective Go](https://github.com/golang/go/wiki/CodeReviewComments) article from Golang project. If you observe offending code, please feel free to send a pull request or ping us on [Slack](https://slack.min.io).
|
||||
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).
|
||||
|
||||
Reference in New Issue
Block a user