|
|
|
@@ -3,19 +3,6 @@
|
|
|
|
|
All contributions should be made via a pull request. This is to ensure a
|
|
|
|
|
certain quality and consistency, that others can rely on.
|
|
|
|
|
|
|
|
|
|
## Roles
|
|
|
|
|
|
|
|
|
|
We differentiate between two roles:
|
|
|
|
|
|
|
|
|
|
- **Maintainers** take responsibility for the recipe. They are listed in the
|
|
|
|
|
[README.md](./README.md), are members of the
|
|
|
|
|
[traefik maintainers team](https://git.coopcloud.tech/org/coop-cloud/teams/traefik-maintainers)
|
|
|
|
|
and fulfil the responsibilities described below.
|
|
|
|
|
- **Contributors with merge access** Trusted people can open pull requests and merge them
|
|
|
|
|
themselves in the cases described in [Pull Requests](#pull-requests).
|
|
|
|
|
|
|
|
|
|
Being allowed to merge a pull request does not make somebody a maintainer.
|
|
|
|
|
|
|
|
|
|
## Maintainer Responsibilities
|
|
|
|
|
|
|
|
|
|
A recipe maintainer has the following responsibilities:
|
|
|
|
@@ -24,74 +11,22 @@ A recipe maintainer has the following responsibilities:
|
|
|
|
|
- Make image security updates within a week
|
|
|
|
|
- Make image major updates every three months
|
|
|
|
|
|
|
|
|
|
In order to fulfill these responsibilities a recipe maintainer:
|
|
|
|
|
In order to fullfill these responsibilities a recipe maintainer:
|
|
|
|
|
|
|
|
|
|
- Has to watch the repository (to get notifications)
|
|
|
|
|
- Needs to make sure renovate is configured properly
|
|
|
|
|
|
|
|
|
|
## Pull Requests
|
|
|
|
|
|
|
|
|
|
As a rule, a pull request can be merged once it has been approved by at least
|
|
|
|
|
one maintainer other than its author. The exceptions below exist so that
|
|
|
|
|
security fixes and routine updates don't get stuck waiting for a review.
|
|
|
|
|
|
|
|
|
|
| Type of change | Approval needed |
|
|
|
|
|
| --- | --- |
|
|
|
|
|
| Security fix | No, can be merged immediately |
|
|
|
|
|
| Regular update | No, after a review window of about one week |
|
|
|
|
|
| Feature, extension or change of the default configuration | Yes, always |
|
|
|
|
|
| Small change that can't break the recipe | No |
|
|
|
|
|
|
|
|
|
|
### Security fixes
|
|
|
|
|
|
|
|
|
|
If a pull request contains a relevant security fix, the person who opened it is
|
|
|
|
|
allowed to merge it directly, without approval and without waiting.
|
|
|
|
|
|
|
|
|
|
The same applies to a pull request that fixes an update which contains a
|
|
|
|
|
security fix: if a version bump can't be merged as it is, because the new
|
|
|
|
|
version needs changes to the configuration, then the pull request that
|
|
|
|
|
makes that update work can be merged directly as well. Otherwise a broken
|
|
|
|
|
update would block a security fix.
|
|
|
|
|
|
|
|
|
|
Keep these pull requests as small as possible, so they contain nothing but what
|
|
|
|
|
is needed to get the fix out.
|
|
|
|
|
|
|
|
|
|
### Regular updates
|
|
|
|
|
|
|
|
|
|
If a pull request rolls out a regular update, there is a time window of about
|
|
|
|
|
one week for other maintainers to review it and to request changes. If no other
|
|
|
|
|
maintainer is available within this time window, the person who opened it is
|
|
|
|
|
allowed to merge it without approval.
|
|
|
|
|
|
|
|
|
|
### Features, extensions and default configuration
|
|
|
|
|
|
|
|
|
|
Any pull request that adds a feature or an extension, or changes the default
|
|
|
|
|
configuration, needs an approval, no matter who opened it. These are the
|
|
|
|
|
changes most likely to break existing deployments.
|
|
|
|
|
|
|
|
|
|
### Small changes
|
|
|
|
|
|
|
|
|
|
Small changes that definitely won't break the recipe can be merged without
|
|
|
|
|
approval, for example:
|
|
|
|
|
|
|
|
|
|
- a new environment variable that is commented out by default
|
|
|
|
|
- a new `abra.sh` function
|
|
|
|
|
- changes to the [README.md](./README.md)
|
|
|
|
|
- writing new tests
|
|
|
|
|
- configuring renovate
|
|
|
|
|
|
|
|
|
|
If a pull request falls into more than one of these categories, the stricter
|
|
|
|
|
rule applies. If you are unsure which category a pull request belongs to, ask
|
|
|
|
|
for an approval.
|
|
|
|
|
|
|
|
|
|
Even though it is okay to merge a pull request with a single approval, it is
|
|
|
|
|
always better if all maintainers looked at the pull request and approved it.
|
|
|
|
|
A pull request can be merged if it is approved by at least one maintainer. For
|
|
|
|
|
pull requests opened by a maintainer they need to be approved by another
|
|
|
|
|
maintainer. Even though it is okay to merge a pull request with one approval, it
|
|
|
|
|
is always better if all maintainers looked at the pull request and approved it.
|
|
|
|
|
|
|
|
|
|
## Become a maintainer
|
|
|
|
|
|
|
|
|
|
Everyone can apply to be a recipe maintainer:
|
|
|
|
|
|
|
|
|
|
1. Watch the repository to always get updates
|
|
|
|
|
2. Simply add your self to the list in the [README.md](./README.md) and open a new pull request with the change.
|
|
|
|
|
3. Once the pull request gets merged you will be added to the [traefik maintainers team](https://git.coopcloud.tech/org/coop-cloud/teams/traefik-maintainers).
|
|
|
|
|
4. Join the room [#cc-|-traefik-maintenance:matrix.org](https://matrix.to/#/%23cc-%7C-traefik-maintenance:matrix.org) and chat to other maintainers.
|
|
|
|
|
4. Join the room [#cc-|-traefik-maintenance:matrix.org](#cc-|-traefik-maintenance:matrix.org) and chat to other maintainers.
|
|
|
|
|
javielico