diff --git a/docs/maintainers/CHANGELOG.md b/docs/maintainers/CHANGELOG.md deleted file mode 100644 index 8935ad70c..000000000 --- a/docs/maintainers/CHANGELOG.md +++ /dev/null @@ -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. diff --git a/docs/maintainers/LABELS.md b/docs/maintainers/LABELS.md deleted file mode 100644 index 5b8b8bb21..000000000 --- a/docs/maintainers/LABELS.md +++ /dev/null @@ -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 | diff --git a/docs/maintainers/PULL_REQUESTS.md b/docs/maintainers/PULL_REQUESTS.md deleted file mode 100644 index 5a627d4cc..000000000 --- a/docs/maintainers/PULL_REQUESTS.md +++ /dev/null @@ -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. diff --git a/docs/maintainers/RELEASES.md b/docs/maintainers/RELEASES.md deleted file mode 100644 index 7eb2522cf..000000000 --- a/docs/maintainers/RELEASES.md +++ /dev/null @@ -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 -``` - -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