docs: Remove maintainers folder (#15339)
This commit is contained in:
Joshua Powers
GitHub
parent
71b58ddaf5
commit
96d5fb3c23
|
|
@ -1,43 +0,0 @@
|
||||||
# Changelog
|
|
||||||
|
|
||||||
The changelog contains the list of changes by version in addition to release
|
|
||||||
notes. The file is updated immediately after adding a change that impacts
|
|
||||||
users. Changes that don't effect the functionality of Telegraf, such as
|
|
||||||
refactoring code, are not included.
|
|
||||||
|
|
||||||
The changelog entries are added by a maintainer after merging a pull request.
|
|
||||||
We experimented with requiring the pull request contributor to add the entry,
|
|
||||||
which had a nice side-effect of reducing the number of changelog only commits
|
|
||||||
in the log history, however this had several drawbacks:
|
|
||||||
|
|
||||||
- The entry often needed reworded.
|
|
||||||
- Entries frequently caused merge conflicts.
|
|
||||||
- Required contributor to know which version a change was accepted into.
|
|
||||||
- Merge conflicts made it more time consuming to backport changes.
|
|
||||||
|
|
||||||
Changes are added only to the first version a change is added in. For
|
|
||||||
example, a change backported to 1.7.2 would only appear under 1.7.2 and not in
|
|
||||||
1.8.0. This may become confusing if we begin supporting more than one
|
|
||||||
previous version but works well for now.
|
|
||||||
|
|
||||||
## Updating
|
|
||||||
|
|
||||||
If the change resulted in deprecation, mention the deprecation in the Release
|
|
||||||
Notes section of the version. In general all changes that require or
|
|
||||||
recommend the user to perform an action when upgrading should be mentioned in
|
|
||||||
the release notes.
|
|
||||||
|
|
||||||
If a new plugin has been added, include it in a section based on the type of
|
|
||||||
the plugin.
|
|
||||||
|
|
||||||
All user facing changes, including those already mentioned in the release
|
|
||||||
notes or new plugin sections, should be added to either the Features or
|
|
||||||
Bugfixes section.
|
|
||||||
|
|
||||||
Features should generally link to the pull request since this describes the
|
|
||||||
actual implementation. Bug fixes should link to the issue instead of the pull
|
|
||||||
request since this describes the problem, if a bug has been fixed but does not
|
|
||||||
have an issue then it is okay to link to the pull request.
|
|
||||||
|
|
||||||
It is usually okay to just use the shortlog commit message, but if needed
|
|
||||||
it can differ or be further clarified in the changelog.
|
|
||||||
|
|
@ -1,69 +0,0 @@
|
||||||
# Labels
|
|
||||||
|
|
||||||
This page describes the meaning of the various
|
|
||||||
[labels](https://github.com/influxdata/telegraf/labels) we use on the Github
|
|
||||||
issue tracker.
|
|
||||||
|
|
||||||
## Categories
|
|
||||||
|
|
||||||
New issues are automatically labeled `feature request`, `bug`, or `support`.
|
|
||||||
If you are unsure what problem the author is proposing, you can use the `need more info` label
|
|
||||||
and if there is another issue you can add the `closed/duplicate` label and close the
|
|
||||||
new issue.
|
|
||||||
|
|
||||||
New pull requests are usually labeled one of `enhancement`, `bugfix` or `new
|
|
||||||
plugin`.
|
|
||||||
|
|
||||||
## Additional Labels
|
|
||||||
|
|
||||||
Apply any of the `area/*` labels that match. If an area doesn't exist, new
|
|
||||||
ones can be added but **it is not a goal to have an area for all issues.**
|
|
||||||
|
|
||||||
If the issue only applies to one platform, you can use a `platform/*` label.
|
|
||||||
These are only applied to single platform issues which are not on Linux.
|
|
||||||
|
|
||||||
For bugs you may want to add `panic`, `regression`, or `upstream` to provide
|
|
||||||
further detail.
|
|
||||||
|
|
||||||
Summary of Labels:
|
|
||||||
|
|
||||||
| Label | Description | Purpose |
|
|
||||||
| --- | ----------- | ---|
|
|
||||||
| `area/*` | These labels each corresponding to a plugin or group of plugins that can be added to identify the affected plugin or group of plugins | categorization |
|
|
||||||
| `breaking change` | Improvement to Telegraf that requires breaking changes to the plugin or agent; for minor/major releases | triage |
|
|
||||||
| `bug` | New issue for an existing component of Telegraf | triage |
|
|
||||||
| `cloud` | Issues or request around cloud environments | categorization |
|
|
||||||
| `dependencies` | Pull requests that update a dependency file | triage |
|
|
||||||
| `discussion` | Issues open for discussion | community/categorization |
|
|
||||||
| `documentation` | Issues related to Telegraf documentation and configuration descriptions | categorization |
|
|
||||||
| `error handling` | Issues related to error handling | categorization |
|
|
||||||
| `external plugin` | Plugins that would be ideal external plugin and expedite being able to use plugin w/ Telegraf | categorization |
|
|
||||||
| `good first issue` | This is a smaller issue suited for getting started in Telegraf, Golang, and contributing to OSS | community |
|
|
||||||
| `help wanted` | Request for community participation, code, contribution | community |
|
|
||||||
| `need more info` | Issue triaged but outstanding questions remain | community |
|
|
||||||
| `performance` | Issues or PRs that address performance issues | categorization|
|
|
||||||
| `platform/*` | Issues that only apply to one platform | categorization |
|
|
||||||
| `plugin/*` | Request for new plugins and issues/PRs that are related to plugins | categorization |
|
|
||||||
| `ready for final review` | Pull request has been reviewed and/or tested by multiple users and is ready for a final review | triage |
|
|
||||||
| `rfc` | Request for comment - larger topics of discussion that are looking for feedback | community |
|
|
||||||
| `support` |Telegraf questions, may be directed to community site or slack | triage |
|
|
||||||
| `upstream` | Bug or issues that rely on dependency fixes and we cannot fix independently | triage |
|
|
||||||
| `waiting for response` | Waiting for response from contributor | community/triage |
|
|
||||||
| `wip` | PR still Work In Progress, not ready for detailed review | triage |
|
|
||||||
|
|
||||||
Labels starting with `pm` are not applied by maintainers.
|
|
||||||
|
|
||||||
## Closing Issues
|
|
||||||
|
|
||||||
We close issues for the following reasons:
|
|
||||||
|
|
||||||
| Label | Reason |
|
|
||||||
| --- | ----------- |
|
|
||||||
| `closed/as-designed` | Labels to be used when closing an issue or PR with short description why it was closed |
|
|
||||||
| `closed/duplicate` | This issue or pull request already exists |
|
|
||||||
| `closed/external-candidate` | The feature request is best implemented by an external plugin |
|
|
||||||
| `closed/external-issue` | The feature request is best implemented by an external plugin |
|
|
||||||
| `closed/needs more info` | Did not receive the information we need within 3 months from last activity on issue |
|
|
||||||
| `closed/not-reproducible` | Given the information we have we can't reproduce the issue |
|
|
||||||
| `closed/out-of-scope` | The feature request is out of scope for Telegraf - highly unlikely to be worked on |
|
|
||||||
| `closed/question` | This issue is a support question, directed to community site or slack |
|
|
||||||
|
|
@ -1,72 +0,0 @@
|
||||||
# Pull Requests
|
|
||||||
|
|
||||||
## Before Review
|
|
||||||
|
|
||||||
Ensure that the CLA is signed (the `telegraf-tiger` bot performs this check). The
|
|
||||||
only exemption would be non-copyrightable changes such as fixing a typo.
|
|
||||||
|
|
||||||
Check that all tests are passing. Due to intermittent errors in the CI tests
|
|
||||||
it may be required to check the cause of test failures and restart failed
|
|
||||||
tests and/or create new issues to fix intermittent test failures.
|
|
||||||
|
|
||||||
Ensure that PR is opened against the master branch as all changes are merged
|
|
||||||
to master initially. It is possible to change the branch a pull request is
|
|
||||||
opened against but it often results in many conflicts, change it before
|
|
||||||
reviewing and then if needed ask the contributor to rebase.
|
|
||||||
|
|
||||||
Ensure there are no merge conflicts. If there are conflicts, ask the
|
|
||||||
contributor to merge or rebase.
|
|
||||||
|
|
||||||
## Review
|
|
||||||
|
|
||||||
[Review the pull request](https://github.com/influxdata/telegraf/blob/master/docs/developers/REVIEWS.md).
|
|
||||||
|
|
||||||
## Merge
|
|
||||||
|
|
||||||
Determine what release the change will be applied to. New features should
|
|
||||||
be added only to master, and will be released in the next minor version (1.x).
|
|
||||||
Bug fixes can be backported to the current release branch to go out with the
|
|
||||||
next patch release (1.7.x) unless the bug is too risky to backport or there is
|
|
||||||
an easy workaround. Set the correct milestone on the pull request and any
|
|
||||||
associated issue.
|
|
||||||
|
|
||||||
All pull requests are merged using the "Squash and Merge" strategy on Github.
|
|
||||||
This method is used because many pull requests do not have a clean change
|
|
||||||
history and this method allows us to normalize commit messages as well as
|
|
||||||
simplifies backporting.
|
|
||||||
|
|
||||||
### Rewriting the commit message
|
|
||||||
|
|
||||||
After selecting "Squash and Merge" you may need to rewrite the commit message.
|
|
||||||
Usually the body of the commit messages should be cleared as well, unless it
|
|
||||||
is well written and applies to the entire changeset.
|
|
||||||
|
|
||||||
- Use imperative present tense for the first line of the message:
|
|
||||||
- Use "Add tests for" (instead of "I added tests for" or "Adding tests for")
|
|
||||||
- The default merge commit messages include the PR number at the end of the
|
|
||||||
commit message, keep this in the final message.
|
|
||||||
- If applicable mention the plugin in the message.
|
|
||||||
|
|
||||||
**Example Enhancement:**
|
|
||||||
|
|
||||||
> Add user tag to procstat input (#4386)
|
|
||||||
|
|
||||||
**Example Bug Fix:**
|
|
||||||
|
|
||||||
> Fix output format of printer processor (#4417)
|
|
||||||
|
|
||||||
## After Merge
|
|
||||||
|
|
||||||
[Update the Changelog](https://github.com/influxdata/telegraf/blob/master/docs/maintainers/CHANGELOG.md).
|
|
||||||
|
|
||||||
If required, backport the patch and the changelog update to the current
|
|
||||||
release branch. Usually this can be done by cherry picking the commits:
|
|
||||||
|
|
||||||
```shell
|
|
||||||
git cherry-pick -x aaaaaaaa bbbbbbbb
|
|
||||||
```
|
|
||||||
|
|
||||||
Backporting changes to the changelog often pulls in unwanted changes. After
|
|
||||||
cherry picking commits, double check that the only the expected lines are
|
|
||||||
modified and if needed clean up the changelog and amend the change. Push the
|
|
||||||
new master and release branch to Github.
|
|
||||||
|
|
@ -1,107 +0,0 @@
|
||||||
# Releases
|
|
||||||
|
|
||||||
## Release Branch
|
|
||||||
|
|
||||||
On master, update `etc/telegraf.conf` and commit:
|
|
||||||
|
|
||||||
```sh
|
|
||||||
./telegraf config > etc/telegraf.conf
|
|
||||||
```
|
|
||||||
|
|
||||||
Create the new release branch:
|
|
||||||
|
|
||||||
```sh
|
|
||||||
git checkout -b release-1.15
|
|
||||||
```
|
|
||||||
|
|
||||||
Push the changes:
|
|
||||||
|
|
||||||
```sh
|
|
||||||
git push origin release-1.15 master
|
|
||||||
```
|
|
||||||
|
|
||||||
Update next version strings on master:
|
|
||||||
|
|
||||||
```sh
|
|
||||||
git checkout master
|
|
||||||
echo 1.16.0 > build_version.txt
|
|
||||||
```
|
|
||||||
|
|
||||||
## Release Candidate
|
|
||||||
|
|
||||||
Release candidates are created only for new minor releases (ex: 1.15.0). Tags
|
|
||||||
are created but some of the other tasks, such as adding a changelog entry are
|
|
||||||
skipped. Packages are added to the github release page and posted to
|
|
||||||
community but are not posted to package repos or docker hub.
|
|
||||||
|
|
||||||
```sh
|
|
||||||
git checkout release-1.15
|
|
||||||
git commit --allow-empty -m "Telegraf 1.15.0-rc1"
|
|
||||||
git tag -s v1.15.0-rc1 -m "Telegraf 1.15.0-rc1"
|
|
||||||
git push origin release-1.15 v1.15.0-rc1
|
|
||||||
```
|
|
||||||
|
|
||||||
## Release
|
|
||||||
|
|
||||||
On master, set the release date in the changelog and cherry-pick the change
|
|
||||||
back:
|
|
||||||
|
|
||||||
```sh
|
|
||||||
git checkout master
|
|
||||||
vi CHANGELOG.md
|
|
||||||
git commit -m "Set 1.8.0 release date"
|
|
||||||
git checkout release-1.8
|
|
||||||
git cherry-pick -x <rev>
|
|
||||||
```
|
|
||||||
|
|
||||||
Double check that the changelog was applied as desired, or fix it up and
|
|
||||||
amend the change before pushing.
|
|
||||||
|
|
||||||
Tag the release:
|
|
||||||
|
|
||||||
```sh
|
|
||||||
git checkout release-1.8
|
|
||||||
# This just improves the `git show 1.8.0` output
|
|
||||||
git commit --allow-empty -m "Telegraf 1.8.0"
|
|
||||||
git tag -s v1.8.0 -m "Telegraf 1.8.0"
|
|
||||||
```
|
|
||||||
|
|
||||||
Check that the version was set correctly, the tag can always be altered if a
|
|
||||||
mistake is made but only before you push it to Github:
|
|
||||||
|
|
||||||
```sh
|
|
||||||
make
|
|
||||||
./telegraf --version
|
|
||||||
Telegraf v1.8.0 (git: release-1.8 aaaaaaaa)
|
|
||||||
```
|
|
||||||
|
|
||||||
When you push a branch with a tag to Github, CircleCI will be triggered to
|
|
||||||
build the packages.
|
|
||||||
|
|
||||||
```sh
|
|
||||||
git push origin master release-1.8 v1.8.0
|
|
||||||
```
|
|
||||||
|
|
||||||
Set the release notes on Github.
|
|
||||||
|
|
||||||
Update webpage download links.
|
|
||||||
|
|
||||||
Update apt and yum repositories hosted at repos.influxdata.com.
|
|
||||||
|
|
||||||
Update the package signatures on S3, these are used primarily by the docker images.
|
|
||||||
|
|
||||||
Update docker image [influxdata/influxdata-docker](https://github.com/influxdata/influxdata-docker):
|
|
||||||
|
|
||||||
```sh
|
|
||||||
cd influxdata-docker
|
|
||||||
git co master
|
|
||||||
git pull
|
|
||||||
git co -b telegraf-1.8.0
|
|
||||||
telegraf/1.8/Dockerfile
|
|
||||||
telegraf/1.8/alpine/Dockerfile
|
|
||||||
git commit -am "telegraf 1.8.0"
|
|
||||||
```
|
|
||||||
|
|
||||||
Official company post to RSS/community.
|
|
||||||
|
|
||||||
Update documentation on docs.influxdata.com
|
|
||||||
Loading…
Reference in New Issue