Skip to content
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

Open
8 tasks
nknize opened this issue Jun 9, 2023 · 6 comments
Open
8 tasks
Labels
Meta Meta issues serve as top level issues that group lower level changes into one bigger effort. process

Comments

@nknize
Copy link
Contributor

nknize commented Jun 9, 2023

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 nknize added Meta Meta issues serve as top level issues that group lower level changes into one bigger effort. process labels Jun 9, 2023
@nknize
Copy link
Contributor Author

nknize commented Jun 9, 2023

/cc @bbarani

@dblock
Copy link
Member

dblock commented Jun 9, 2023

@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
Copy link
Contributor Author

nknize commented Jun 9, 2023

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:

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
Copy link
Contributor Author

nknize commented Jun 9, 2023

@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
Copy link
Member

bbarani commented Jun 11, 2023

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

@bbarani
Copy link
Member

bbarani commented Jun 21, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Meta Meta issues serve as top level issues that group lower level changes into one bigger effort. process
Projects
None yet
Development

No branches or pull requests

4 participants