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