-
Notifications
You must be signed in to change notification settings - Fork 70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Meta] Establish Public OpenSearch Release Process with Supporting Documentation #166
Comments
/cc @bbarani |
@nknize A lot of the mechanics exist at various degrees of thoroughness in https://github.com/opensearch-project/opensearch-build#releasing-opensearch and has been iterated upon incrementally. As an example, the top-level release process is codified through release tickets in https://github.com/opensearch-project/opensearch-build/blob/main/.github/ISSUE_TEMPLATE/release_template.md. What are the major pieces missing that are not in there? Maybe just add words? |
Possibly just words? Maybe a complete refactor of this documentation to be more community friendly by way of a simple top level process that pulls the disparate pieces together in a single place, and teases it away from things like code of conduct, contributing, etc. It needs to be simple for any community member to initiate a release. Mechanisms are missing like public communication templates for smoke testing the release such as: ########################################################################################### The artifacts can be downloaded from:
You can execute the tests directly using the below command: Testing the Distribution More info on testing the distribution: https://github.com/opensearch-project/opensearch-build/blob/main/README.md#testing-the-distribution The vote will be open until next Monday, i.e. until 2023-05-23 11:00 UTC. [ ] +1 approve ########################################################################################### I think we should have a good single RELEASE_PROCESS.md for formalizing just the release process, something like:
On-boarding a new plugin shouldn't be in the release process doc. It should be a separate process that documents the governance around how the project maintainers (maybe future PMC) collectively decide (e.g., vote?) to include a new plugin into the "ecosystem". The current release documents are a good starting point. I think that simplifies the sub tasks in this meta issue maybe down to just a cross link from the top level RELEASE_PROCESS.md |
@bbarani do you want to open a PR for the top level RELEASE_PROCESS.md? The follow on PRs may not need to be individual .md files for the "Documentation" maybe they're just links to existing MD files that make it easier for the community to grok. |
OpenSearch is a fast-growing community-contributed project consisting of multiple repositories with ~600 contributors who actively participate in the day-to-day growth of the project. The OpenSearch Project team has been hosting public meetings for some time, where community members can join the meetings and actively participate in the development activities alongside the maintainers. The release activities, operations, and feature discussions, however, are primarily driven by privileged organization members with domain knowledge not fully transparent to the community. As an open source project, it is imperative that OpenSearch move towards a fully transparent release process that can be jointly owned or participated by any member of the OpenSearch Maintainer community. This includes release planning, and concrete tasks needed to build, stage, test, and release the production ready artifacts. This meta issue captures the process and howTo documents needed to enable any OpenSearch maintainer to participate in (or drive) the OpenSearch release cycle in a fully transparent way.
The text was updated successfully, but these errors were encountered: