opensource/opentelemetry-python-contrib
1
0
Fork 0
mirror of https://github.com/open-telemetry/opentelemetry-python-contrib.git synced 2025-07-30 21:56:07 +08:00
Code Issues Packages Projects Releases Wiki Activity

README includes 1.0 release checklist + CODEOWNER description (#596)

Browse Source 
* README 1.0 release checklist + what is a CODEOWNER

* Do not required SLA for responding to asks

* Easy changes to address reviewer comments

* Introduce on Slack at least not SIG meeting

* Give guidance when a CODEOWNER wants to leave a project

* Update README.md

Take suggestion package "MUST" wording.

Co-authored-by: Diego Hurtado <ocelotl@users.noreply.github.com>

* Update README.md

Take suggestion on CODEOWNER requirement wording.

Co-authored-by: Diego Hurtado <ocelotl@users.noreply.github.com>

* Apply suggestions from code review

Take more suggestions on checklist list requirements.

Co-authored-by: Diego Hurtado <ocelotl@users.noreply.github.com>

* Update README.md

Take suggestion on MUST requirement for documentation.

* Add back missing bullet point

* Do not say perpetually 1.0 instead say up to maintainers

* Make it explicity CODEOWNER is for 1 file

* Make OTel Community membership a requirement because the action we use requires it

Co-authored-by: Diego Hurtado <ocelotl@users.noreply.github.com>
This commit is contained in:
(Eliseo) Nathaniel Ruiz Nowell
2021-09-08 10:14:20 -07:00
committed by GitHub
parent fd5fc9a101
commit a78c94ce59
3 changed files with 39 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files

21
.github/CODEOWNERS vendored
View File

@ -1,5 +1,26 @@
# Code owners file.
# This file controls who is tagged for review for any given pull request.
#
# What is a "CODEOWNER"?
#
# A CODEOWNER lends their expertise to a specific package hosted by an OpenTelemetry repository.
#
# A CODEOWNER MUST:
# - introduce themselves on the CNCF OTel Python channel: https://cloud-native.slack.com/archives/C01PD4HUVBL
# - have enough knowledge of the corresponding instrumented library
# - respond to issues
# - fix failing unit tests or any other blockers to the CI/CD workflow
# - update usage of `opentelemetry-python-core` APIs upon the introduction of breaking changes
# - be a member of the OpenTelemetry community so that the `component-owners.yml` action to automatically assign CODEOWNERS to PRs works correctly.
#
# For anything not explicitly taken by someone else:
* @open-telemetry/opentelemetry-python-contrib-approvers
# Learn about CODEOWNERS file format:
# https://help.github.com/en/articles/about-code-owners
#
# Learn about membership in OpenTelemetry community:
# https://github.com/open-telemetry/community/blob/main/community-membership.md
#

13
CODEOWNERS
View File

@ -1,13 +0,0 @@
#####################################################
#
# List of approvers and maintainers
#
#####################################################
#
# Learn about membership in OpenTelemetry community:
# https://github.com/open-telemetry/community/blob/main/community-membership.md
#
#
# Learn about CODEOWNERS file format:
# https://help.github.com/en/articles/about-code-owners
#

18
README.md
View File

@ -66,6 +66,24 @@ install](https://pip.pypa.io/en/stable/reference/pip_install/#editable-installs)
pip install -e ./instrumentation/opentelemetry-instrumentation-{integration}
```
## Releasing
Maintainers aim to periodically release new versions of the packages in `opentelemetry-python-contrib`.
Contributions that enhance OTel for Python are welcome to be hosted upstream for the benefit of group collaboration. Maintainers will look for things like good documentation, good unit tests, and in general their own confidence when deciding to release a package with the stability guarantees that are implied with a `1.0` release.
To resolve this, members of the community are encouraged to commit to becoming a CODEOWNER for packages in `-contrib` that they feel experienced enough to maintain. CODEOWNERS can then follow the checklist below to release `-contrib` packages as 1.0 stable:
### Releasing a package as `1.0` stable
To release a package as `1.0` stable, the package:
- SHOULD have a CODEOWNER. To become one, submit an issue and explain why you meet the responsibilities found in [CODEOWNERS](.github/CODEOWNERS).
- MUST have unit tests that cover all supported versions of the instrumented library.
- e.g. Instrumentation packages might use different techniques to instrument different major versions of python packages
- MUST have clear documentation for non-obvious usages of the package
- e.g. If an instrumentation package uses flags, a token as context, or parameters that are not typical of the `BaseInstrumentor` class, these are documented
- After the release of `1.0`, a CODEOWNER may no longer feel like they have the bandwidth to meet the responsibilities of maintaining the package. That's not a problem at all, life happens! However, if that is the case, we ask that the CODEOWNER please raise an issue indicating that they would like to be removed as a CODEOWNER so that they don't get pinged on future PRs. Ultimately, we hope to use that issue to find a new CODEOWNER.
## Contributing
See [CONTRIBUTING.md](CONTRIBUTING.md)