mirror of https://github.com/pgsty/minio.git synced 2026-08-09 07:43:29 +03:00

Files

T

Feng Ruohang fd2ca1c6d2 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>

2026-08-06 08:49:30 +08:00

2.7 KiB

Raw Blame History

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

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

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 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.

2.7 KiB Raw Blame History