[Meta] Establish Public OpenSearch Release Process with Supporting Documentation

[nknize]

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.

• Document Top-Level Formal Release Process
• Document communication templates for soliciting community volunteers
• Document technical steps for Feature Freezing the ecosystem
• Document technical steps for creating release candidates (RC)
• Document technical and communication steps for integration, backwards compatibility, smoke, and performance testing the release candidate with the community
• Document technical steps for staging the RC
• Document technical steps for official release of the RC artifacts
• Document post release activities (e.g., announcements, PR, social media)

[nknize]

/cc @bbarani

[dblock]

@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?

[nknize]

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:

###########################################################################################
Please vote for release candidate 1 for OpenSearch 2.10.0

The artifacts can be downloaded from:

• OpenSearch - Build 7771 (Note: Windows version does not have performance analyzer plugin)
  • arm64 [manifest] [tar] [rpm][deb]
  • x64 [manifest] [tar] [rpm] [deb] [windows]
• OpenSearch Dashboards - Build 6100
  • arm64 [manifest] [tar][rpm][deb]
  • x64 [manifest] [tar][rpm] [deb] [windows]

You can execute the tests directly using the below command:

Testing the Distribution
Tests the OpenSearch distribution, including integration, backwards-compatibility and performance tests.
./test.sh

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
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)

###########################################################################################

I think we should have a good single RELEASE_PROCESS.md for formalizing just the release process, something like:

• Release cycle overview
  • "OpenSearch currently releases major, minor and patch versions on a regular cadence as explained in the release page. The infrastructure to automatically build, test and release artifacts are available at https://build.ci.opensearch.org/."
• Roles and Responsibilities
  • Release Manager - blah
  • Repository Manager - blah
  • Maintainers - blah
  • Project Management Committee - blah
• Release Process
  • Here are the steps involved in the OpenSearch Release Process:
    • Preparation
    • Release branch readiness
    • Code complete / feature freeze
    • Release Candidate (RC) creation
    • Integration, BWC, Smoke and Performance Testing
    • Staging the RC
    • Releasing the Candidate
    • Post Release Activities
• Documentation (How To Guides, Announcement Templates)
  • Communication Template for Requesting Release Manager and Repository Volunteers
  • Feature Freeze Process
  • RC Creation Steps
  • Testing Steps and Communication Templates
  • Staging Release Candidate
  • Releasing and Post Release Activities

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

[nknize]

@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.

[bbarani]

@nknize @dblock I will open a PR for RELEASE_PROCESS.md as mentioned in this comment soon.

[bbarani]

@nknize I have opened a RFC along with PR with the steps involved in release cycle process for OpenSearch releases.