From c90da6ff8c028cd7831acdbdf700f3fa063f875d Mon Sep 17 00:00:00 2001 From: Peter Nied Date: Fri, 8 Apr 2022 15:46:56 +0000 Subject: [PATCH 1/3] [Practice] Reverting changes The maintainers had a discussion on how reverts have been done in the past and how we would like to ensure the codebase is always ready for contribution. The theme of that discussion was prioritizing stable and available codebase - documenting that in this change. Signed-off-by: Peter Nied --- MAINTAINERS.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/MAINTAINERS.md b/MAINTAINERS.md index 9ffc16e1c6..f1ae0c6fbf 100644 --- a/MAINTAINERS.md +++ b/MAINTAINERS.md @@ -1,6 +1,9 @@ - [OpenSearch Security Maintainers](#opensearch-security-maintainers) - [Maintainers](#maintainers) - [Updating Practices](#updating-practices) +- [Practices](#practices) + - [Reverting Commits](#reverting-commits) + - [Performing Revert](#performing-revert) # OpenSearch Security Maintainers @@ -14,3 +17,15 @@ ### Updating Practices To ensure common practices as maintainers, all practices are expected to be documented here or enforced through github actions. There should be no expectations beyond what is documented in the repo [CONTRIBUTING.md](./CONTRIBUTING.md) and OpenSearch-Project [CONTRIBUTING.md](https://github.com/opensearch-project/.github/blob/main/CONTRIBUTING.md). To modify an existing processes or create a new one, make a pull request on this MAINTAINERS.md for review and merge it after all maintainers approve of it. + +# Practices + +## Reverting Commits +There will be changes that destabilize or block contributions. The impact of these changes will be localized on the repository or even the entire OpenSearch project. We should bias towards keeping contributions unblocked by immediately reverting impacting changes, these reverts will be done by a maintainer. After the change has been reverted, an issue will be openned to re-merge the change and callout the elements of the contribution that need extra examination such as additional tests or even pull request workflows. + +Exceptional, instead of immediately reverting, if a contributor knows how and will resolve the issue in an hour we should fix-forward to reduce overhead. + +### Performing Revert +Go to the pull request of the change that was an issue, there is a `Revert` button at the bottom. If there are no conflicts to resolve, this can be done immediately bypassing standard approval. + +Reverts can also be done via the command line using `git revert` and creating a new pull request. If done in this way they should have references to the pull request that was reverted. \ No newline at end of file From 1ba40dd5e7aa2a8516e65e207f44f0501cbc536e Mon Sep 17 00:00:00 2001 From: Peter Nied Date: Fri, 8 Apr 2022 21:23:30 +0000 Subject: [PATCH 2/3] Suggestions from owaiskazi19 Signed-off-by: Peter Nied --- MAINTAINERS.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS.md b/MAINTAINERS.md index f1ae0c6fbf..1b7b2d8418 100644 --- a/MAINTAINERS.md +++ b/MAINTAINERS.md @@ -23,9 +23,9 @@ To ensure common practices as maintainers, all practices are expected to be docu ## Reverting Commits There will be changes that destabilize or block contributions. The impact of these changes will be localized on the repository or even the entire OpenSearch project. We should bias towards keeping contributions unblocked by immediately reverting impacting changes, these reverts will be done by a maintainer. After the change has been reverted, an issue will be openned to re-merge the change and callout the elements of the contribution that need extra examination such as additional tests or even pull request workflows. -Exceptional, instead of immediately reverting, if a contributor knows how and will resolve the issue in an hour we should fix-forward to reduce overhead. +Exceptional, instead of immediately reverting, if a contributor knows how and will resolve the issue in an hour or less we should fix-forward to reduce overhead. ### Performing Revert Go to the pull request of the change that was an issue, there is a `Revert` button at the bottom. If there are no conflicts to resolve, this can be done immediately bypassing standard approval. -Reverts can also be done via the command line using `git revert` and creating a new pull request. If done in this way they should have references to the pull request that was reverted. \ No newline at end of file +Reverts can also be done via the command line using `git revert ` and creating a new pull request. If done in this way they should have references to the pull request that was reverted. \ No newline at end of file From 1ffc83ea79a234b93785ba110602eb445230937e Mon Sep 17 00:00:00 2001 From: Peter Nied Date: Fri, 8 Apr 2022 21:29:58 +0000 Subject: [PATCH 3/3] Add newline at the end of the file Signed-off-by: Peter Nied --- MAINTAINERS.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS.md b/MAINTAINERS.md index 1b7b2d8418..ceb525084a 100644 --- a/MAINTAINERS.md +++ b/MAINTAINERS.md @@ -28,4 +28,4 @@ Exceptional, instead of immediately reverting, if a contributor knows how and wi ### Performing Revert Go to the pull request of the change that was an issue, there is a `Revert` button at the bottom. If there are no conflicts to resolve, this can be done immediately bypassing standard approval. -Reverts can also be done via the command line using `git revert ` and creating a new pull request. If done in this way they should have references to the pull request that was reverted. \ No newline at end of file +Reverts can also be done via the command line using `git revert ` and creating a new pull request. If done in this way they should have references to the pull request that was reverted.