mirror of https://github.com/pgsty/minio.git synced 2026-08-09 15:53:28 +03:00

Files

T

Feng Ruohang b57275be34 docs: adopt the no-CLA plus DCO policy and fix copyright terms

Brings the server in line with the contribution and copyright policy
already adopted in pgsty/mc.

Copyright terms were derived from the clock: startupBanner overwrote the
ldflags-injected CopyrightYear with time.Now().Year() and printed it as
the end of MinIO, Inc.'s term, so every January would have extended the
upstream copyright claim past the 2025 end of upstream development, and
release builds silently discarded the injected year. Both banners now
credit MinIO, Inc. for 2015-2025 and PGSTY from 2025 through the
release-stamped year, falling back to the current year in source builds.
NOTICE names PGSTY as the holder of the fork's modifications, matching
the banners and the packaging vendor field.

Contributions are accepted inbound=outbound under AGPL-3.0-or-later with
no CLA - the core is Copyright MinIO, Inc., so the combined work can
never be relicensed and a CLA would buy nothing. What a fork carrying a
downstream delta does need is provenance, so DCO 1.1 sign-off is now
mandatory and enforced by a workflow that rejects unsigned non-bot
commits. CONTRIBUTING documents sign-off, repair, cherry-pick provenance,
dual copyright headers, trailer preservation across squash merges, and
that assistive-tooling trailers carry no authorship or copyright claim.

verify-rebrand.sh pins the copyright split and the policy files so
neither can regress.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Signed-off-by: Feng Ruohang <rh@vonng.com>

2026-08-06 12:43:58 +08:00

5.2 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/silo
cd silo
go build -o silo .
./silo --version

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 and a DCO sign-off (see Licensing of Contributions):

git commit -s -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.

Licensing of Contributions

Silo is licensed under the GNU AGPL v3.0 or later. Its core is Copyright (c) MinIO, Inc.; the combined work can never be relicensed, and this fork does not try to.

No CLA. We do not ask you to sign a Contributor License Agreement and we do not take your copyright. Contributions are accepted inbound=outbound: you keep the copyright to your changes and license them under the same AGPL-3.0-or-later as the project itself. The maintainers receive no rights beyond the project license.
DCO sign-off required. Every commit must carry a Signed-off-by: Your Name <you@example.com> trailer certifying the Developer Certificate of Origin 1.1 — your statement that you have the right to submit the code under the project license. Sign each commit with:
```
git commit -s
```
Forgot some? Repair your branch with git rebase --signoff and force-push. CI rejects pull requests containing unsigned commits; the sign-off email must match the commit author email. (Lowercase -s is the plain-text DCO sign-off; cryptographic -S/GPG signing is welcome but independent.)
Provenance. Only submit code you are entitled to submit. This matters more here than in most projects: Silo carries a downstream delta over an upstream code base, and cherry-picks from the lineage remote or other forks are routine. When relaying a patch written by someone else, preserve original authorship (git cherry-pick -x, keep the author field and any existing Signed-off-by trailers) and add your own sign-off as the person passing it along. Never import code from a proprietary distribution.
File headers. Files derived from upstream keep the original MinIO copyright header unchanged. New files added by this fork use the dual header, followed by the standard AGPL boilerplate:
```
// Copyright (c) 2015-2025 MinIO, Inc.
// Copyright (c) 2025-2026 PGSTY
```
Squash merges must keep the Signed-off-by: trailers in the resulting commit message.
Authorship and tooling. The human contributor is the author of the commit and the sole signatory of its DCO sign-off. Attribution trailers for assistive tooling (for example Co-Authored-By: naming an AI assistant) are informational only: they record which tools were used, and do not create authorship, co-authorship, or any copyright claim. Whoever signs off remains responsible for the content of the commit, whatever produced it.

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.

5.2 KiB Raw Blame History