This is an automated email from the ASF dual-hosted git repository. janhoy pushed a commit to branch main in repository https://gitbox.apache.org/repos/asf/solr-orbit.git
commit c5ba79a7e582cd2f069b624129b1c009fab9a048 Author: Jan Høydahl <[email protected]> AuthorDate: Fri May 22 00:53:31 2026 +0200 Establish ASF legal and governance files for Apache Solr Benchmark Replace OpenSearch-specific project governance with ASF-compatible equivalents: add NOTICE and create-notice.sh for ASF IP compliance, bump version to 0.1.0 to signal the fresh start, update CONTRIBUTING.md for Solr context, remove MAINTAINERS/RELEASE/TRIAGE files that don't apply to an ASF incubating project (those processes are defined by the ASF), drop .whitesource/.fossa.yml OSS-scanning configs that were tied to the OpenSearch project infrastructure. Part of #3 --- .fossa.yml | 2 +- .whitesource | 22 -------- AUTHORS | 50 ------------------ CONTRIBUTING.md | 116 ++++++++++++++++++------------------------ MAINTAINERS.md | 14 ------ MAINTAINERS_GUIDE.md | 45 ----------------- NOTICE | 4 ++ RELEASE_GUIDE.md | 140 --------------------------------------------------- THIRD_PARTY.txt | 9 ---- TRIAGE.md | 68 ------------------------- create-notice.sh | 23 +++------ version.txt | 2 +- 12 files changed, 61 insertions(+), 434 deletions(-) diff --git a/.fossa.yml b/.fossa.yml index 6495aa79..fef8533f 100755 --- a/.fossa.yml +++ b/.fossa.yml @@ -2,7 +2,7 @@ version: 2 cli: server: https://app.fossa.com fetcher: custom - project: OSB + project: solr-benchmark analyze: modules: - name: . diff --git a/.whitesource b/.whitesource deleted file mode 100644 index e34827bf..00000000 --- a/.whitesource +++ /dev/null @@ -1,22 +0,0 @@ -{ - "scanSettings": { - "configMode": "AUTO", - "configExternalURL": "", - "projectToken": "", - "baseBranches": [] - }, - "checkRunSettings": { - "vulnerableCheckRunConclusionLevel": "failure", - "displayMode": "diff", - "useMendCheckNames": true - }, - "issueSettings": { - "minSeverityLevel": "LOW", - "issueType": "DEPENDENCY" - }, - "remediateSettings": { - "workflowRules": { - "enabled": true - } - } -} \ No newline at end of file diff --git a/AUTHORS b/AUTHORS deleted file mode 100644 index c89a8d64..00000000 --- a/AUTHORS +++ /dev/null @@ -1,50 +0,0 @@ -Adrien Grand -Akhil Rane -Alexandros Sapranidis -Aswin Murugesh -Brian Lesperance -Christian Dahlqvist -Christopher Manning -DJRickyB -Dale McDiarmid -Daniel Mitterdorfer -David Turner -Dennis Lawler -Dimitrios Liappis -Evgenia Badiyanova -Evgenia Badyanova -Gavin Fowler -Guido Lena Cota -Hendrik Muhs -Honza Král -Irina Truong -Itamar Syn-Hershko -Jason Tedor -Jim Ferenczi -John Sobanski -Joshua Rich -Kevin Quick -Keyur Doshi -Krishna Dattu Koneru -Lee Hinman -Lucas Bremgartner -Lyndon Swan -Maciek Sufa -Magnus Kessler -Martijn van Groningen -Matt Veitas -Michael Basnight -Michael McCandless -Nicholas Knize -Paul Coghlan -Peter Dyson -Rick Boyd -Rohit Nair -Thomas Decaux -Tobias Suckow -Vitor Anjos -Vladimir Masarik -gdmello -nicholaskuechler -sstults -tomcallahan diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 1fc65d3a..f43add8c 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,54 +1,51 @@ -- [Contributing to OpenSearch Benchmark](#contributing-to-opensearch-benchmark) - - [First Things First](#first-things-first) - - [Ways to Contribute](#ways-to-contribute) - - [Bug Reports](#bug-reports) - - [Feature Requests](#feature-requests) - - [Documentation Changes](#documentation-changes) - - [Contributing Code](#contributing-code) - - [Developer Certificate of Origin](#developer-certificate-of-origin) - - [Review Process](#review-process) +# Contributing to Apache Solr Benchmark -# Contributing to OpenSearch Benchmark - -OpenSearch Benchmark is a community project that is built and maintained by people just like **you**. We're glad you're interested in helping out. There are several different ways you can do it, but before we talk about that, let's talk about how to get started. +Apache Solr Benchmark is a community project built by people like **you**. +We're glad you're interested in contributing. ## First Things First -1. **When in doubt, open an issue** - For almost any type of contribution, the first step is opening an issue. Even if you think you already know what the solution is, writing down a description of the problem you're trying to solve will help everyone get context when they review your pull request. If it's truly a trivial change (e.g. spelling error), you can skip this step -- but as the subject says, when it doubt, [open an issue](https://github.com/opensearch-project/OpenSearch-Benchma [...] +1. **When in doubt, open an issue** — before making changes, open an issue to + describe the problem or feature. This avoids duplicated effort and lets the + community agree on the right direction before you invest time in a PR. -2. **Only submit your own work** (or work you have sufficient rights to submit) - Please make sure that any code or documentation you submit is your work or you have the rights to submit. We respect the intellectual property rights of others, and as part of contributing, we'll ask you to sign your contribution with a "Developer Certificate of Origin" (DCO) that states you have the rights to submit this work and you understand we'll use your contribution. There's more information about t [...] +2. **Only submit your own work** — ensure any code or documentation you submit + is yours or you have the right to submit it. See the + [DCO section](#developer-certificate-of-origin) below. ## Ways to Contribute -**Please note:** OpenSearch Benchmark is a fork of [Rally](https://github.com/elastic/rally), and is a work in progress. If you do find references to Rally (outside of attributions and copyrights!) please [open an issue](https://github.com/opensearch-project/OpenSearch-Benchmark/issues). - -### Bug Reports <REVIEW FROM HERE> - -Ugh! Bugs! - -A bug is when software behaves in a way that you didn't expect and the developer didn't intend. To help us understand what's going on, we first want to make sure you're working from the latest version. Please make sure you're testing against the [latest version](https://github.com/opensearch-project/OpenSearch-Benchmark). - -Once you've confirmed that the bug still exists in the latest version, you'll want to check to make sure it's not something we already know about on the [open issues GitHub page](https://github.com/opensearch-project/OpenSearch-Benchmark/issues). +### Bug Reports -Provide as much information as you can. You may think that the problem lies with your query, when actually it depends on how your data is indexed. The easier it is for us to recreate your problem, the faster it is likely to be fixed. +Please confirm you are on the latest code, then open an issue with: +- Steps to reproduce +- Expected vs. actual behaviour +- Solr version and benchmark configuration ### Feature Requests -If you've thought of a way that OpenSearch Benchmark could be better, we want to hear about it. We track feature requests using GitHub, so please feel free to open an issue which describes the feature you would like to see, why you need it, and how it should work. +Open an issue describing the feature, the motivation, and a rough design sketch. ### Contributing Code -As with other types of contributions, the first step is to [**open an issue on GitHub**](https://github.com/opensearch-project/OpenSearch-Benchmark/issues/new/choose). Opening an issue before you make changes makes sure that someone else isn't already working on that particular problem. It also lets us all work together to find the right approach before you spend a bunch of time on a PR. So again, when in doubt, open an issue. - -Once you've opened an issue, check out our [Developer Guide](./DEVELOPER_GUIDE.md) for instructions on how to get started. +1. Open an issue first (see above). +2. Read the [Developer Guide](./DEVELOPER_GUIDE.md). +3. Fork the repository, create a branch, make your changes, and open a PR. +4. Sign each commit with a DCO `Signed-off-by` line. ## Developer Certificate of Origin -OpenSearch Benchmark is an open source product released under the Apache 2.0 license (see either [the Apache site](https://www.apache.org/licenses/LICENSE-2.0) or the [LICENSE file](./LICENSE)). The Apache 2.0 license allows you to freely use, modify, distribute, and sell your own products that include Apache 2.0 licensed software. +Apache Solr Benchmark is released under the Apache 2.0 license. We use a +Developer Certificate of Origin (DCO) to ensure all contributions are properly +attributed. -We respect intellectual property rights of others and we want to make sure all incoming contributions are correctly attributed and licensed. A Developer Certificate of Origin (DCO) is a lightweight mechanism to do that. +Each commit must include: -The DCO is a declaration attached to every contribution made by every developer. In the commit message of the contribution, the developer simply adds a `Signed-off-by` statement and thereby agrees to the DCO, which you can find below or at [DeveloperCertificate.org](http://developercertificate.org/). +``` +Signed-off-by: Your Name <[email protected]> +``` + +Add it automatically with `git commit -s`. The full DCO text: ``` Developer's Certificate of Origin 1.1 @@ -59,45 +56,28 @@ By making a contribution to this project, I certify that: have the right to submit it under the open source license indicated in the file; or -(b) The contribution is based upon previous work that, to the - best of my knowledge, is covered under an appropriate open - source license and I have the right under that license to - submit that work with modifications, whether created in whole - or in part by me, under the same open source license (unless - I am permitted to submit under a different license), as - Indicated in the file; or - -(c) The contribution was provided directly to me by some other - person who certified (a), (b) or (c) and I have not modified - it. - -(d) I understand and agree that this project and the contribution - are public and that a record of the contribution (including - all personal information I submit with it, including my - sign-off) is maintained indefinitely and may be redistributed - consistent with this project or the open source license(s) - involved. - ``` - -We require that every contribution to OpenSearch Benchmark is signed with a Developer Certificate of Origin. Additionally, please use your real name. We do not accept anonymous contributors nor those utilizing pseudonyms. - -Each commit must include a DCO which looks like this - -``` -Signed-off-by: Jane Smith <[email protected]> +(b) The contribution is based upon previous work that, to the best + of my knowledge, is covered under an appropriate open source + license and I have the right under that license to submit that + work with modifications, whether created in whole or in part by + me, under the same open source license (unless I am permitted to + submit under a different license), as indicated in the file; or + +(c) The contribution was provided directly to me by some other person + who certified (a), (b) or (c) and I have not modified it. + +(d) I understand and agree that this project and the contribution are + public and that a record of the contribution (including all personal + information I submit with it, including my sign-off) is maintained + indefinitely and may be redistributed consistent with this project + or the open source license(s) involved. ``` -You may type this line on your own when writing your commit messages. However, if your user.name and user.email are set in your git configs, you can use `-s` or `--signoff` to add the `Signed-off-by` line to the end of the commit message. ## Review Process -We deeply appreciate everyone who takes the time to make a contribution. We aim to review all contributions promptly but cannot guarantee quick turnaround times. It can take time for appropriate analysis, verification and testing, to understand the implications and ramifications of the proposed change, and for discussion with other maintainers and developers. Furthermore, it is essential that contributions remain accessible for an adequate duration to allow healthy engagement by communit [...] - -Please note that there is a code freeze imposed starting a week before every release to ensure stability of the codebase and a smooth release process. If you are interested in getting a change into the next release, please submit your change well in advance, so that it is approved and merged in prior to the deadline for the freeze. We are in the process of implementing snapshot releases, so if your change does not make a particular release, the appropriate snapshot release can be used un [...] - -As a reminder, [opening an issue](https://github.com/opensearch-project/OpenSearch-Benchmark/issues/new/choose) discussing your change before you make it is the best way to smooth the PR process. This will prevent a rejection because someone else is already working on the problem, or because the solution is incompatible with the architectural direction. - -During the PR process, expect that there will be some back-and-forth. Please try to respond to comments in a timely fashion, and if you don't wish to continue with the PR, let us know. If a PR takes too many iterations for its complexity or size, we may reject it. Additionally, if you stop responding we may close the PR as abandoned. In either case, if you feel this was done in error, please add a comment on the PR. - -If we accept the PR, a [maintainer](MAINTAINERS.md) will merge your change and usually take care of backporting it to appropriate branches ourselves. +We aim to review contributions promptly. To smooth the process: -If we reject the PR, we will close the pull request with a comment explaining why. This decision isn't always final: if you feel we have misunderstood your intended change or otherwise think that we should reconsider then please continue the conversation with a comment on the PR and we'll do our best to address any further points you raise. +- Reference the related issue in your PR description. +- Keep PRs focused; a narrow PR is easier to review than a large one. +- Respond to review comments in a timely manner. +- If you stop working on a PR, let us know so we can close or reassign it. diff --git a/MAINTAINERS.md b/MAINTAINERS.md deleted file mode 100644 index 4b3d4641..00000000 --- a/MAINTAINERS.md +++ /dev/null @@ -1,14 +0,0 @@ -## Overview - -This document contains a list of maintainers in this repo. See [opensearch-project/.github/RESPONSIBILITIES.md](https://github.com/opensearch-project/.github/blob/main/RESPONSIBILITIES.md#maintainer-responsibilities) that explains what the role of maintainer means, what maintainers do in this and other repos, and how they should be doing it. If you're interested in contributing, and becoming a maintainer, see [CONTRIBUTING](CONTRIBUTING.md). - -## Current Maintainers - -| Maintainer | GitHub ID | Affiliation | Email Address | -| ----------------------- | ----------------------------------------------------- | ----------- | --------------------------------- | -| Ian Hoang | [IanHoang](https://github.com/IanHoang) | Amazon | [email protected] | -| Govind Kamat | [gkamat](https://github.com/gkamat) | Amazon | [email protected] | -| Mingyang Shi | [beaioun](https://github.com/beaioun) | OSCI | [email protected] | -| Rishabh Singh | [rishabh6788](https://github.com/rishabh6788) | Amazon | [email protected] | -| Vijayan Balasubramanian | [VijayanB](https://github.com/VijayanB) | Amazon | [email protected] | -| Michael Oviedo | [OVI3D0](https://github.com/OVI3D0) | Amazon | [email protected] | diff --git a/MAINTAINERS_GUIDE.md b/MAINTAINERS_GUIDE.md deleted file mode 100644 index 73f156d3..00000000 --- a/MAINTAINERS_GUIDE.md +++ /dev/null @@ -1,45 +0,0 @@ -# Maintainers Guide - -## Responsibilities - -### Work on Current Issues and Create New Issues - -* Maintainers can select any issues they would like to work on and should add should add them to the `In Progress` column of the [roadmap board](https://github.com/opensearch-project/opensearch-benchmark/projects/1). Any issue added to the `In Progress` column should be properly labeled. For more information on how to properly label issues and PRs, see the [labels](#labels) section of this document. - -Maintainers should create new issues as needed. - -### Triage Issues -* Maintainers should meet biweekly to triage issues. This involves assessing new, current, and old issues and prioritizing them based on the [roadmap board](https://github.com/opensearch-project/opensearch-benchmark/projects/1). - -### Review Pull Requests - -* Maintainers should regularly review the backlog of pull requests. Pull requests only require one maintainer to approve. The maintainer reviewing the PRs should be a subject matter expert (understand the context and purpose of the PR) and drive best practices in clean code and architecture. -* Only use GitHub's squash-and-merge to merge into `main`. Else, the backport workflow can fail -- it does not handle multiple commits as with rebases. Merges lead to an undesired merge commit. -* Use the `backport 3` label for every PR, since main should be the image of `3`, at least until OpenSearch version 3 is officially released. Add other branch labels appropriately; almost certainly `backport 2` will also be needed, since this is the current OpenSearch version. -* Close out the backport PRs in chronological order. If you close out a PR on `main`, please close out the associated branch PRs as well. They get generated in a few minutes by the automated backport workflow. Once they are merged in, the backport branches can be deleted as well. - -### Drive Releases -* Maintainers drive releases. A week prior to the scheduled release, maintainers should announce a code freeze in the [#performance channel](https://opensearch.slack.com/archives/C0516H8EJ7R) within the OpenSearch Slack community. For more information on the release process, see the [release guide](<https://github.com/opensearch-project/OpenSearch-Benchmark/blob/main/RELEASE_GUIDE.md>) - - -## Labels - -Issues, pull requests and releases may be tagged with labels to categorize them. Here are some suggestions on how to use labels. - -Priorities are set by Maintainers of the repository and should be assigned to a selected subset of issues and not all issues. - -* **Low Priority** - Implementations and PRs should be reviewed and completed within a sprint -* **Medium Priority** - Implementations and PRs should be reviewed and completed within a week -* **High Priority** - Implementations and PRs should be reviewed and completed within a few days and up to a week - - -**Release Labels:** Releases are tagged with labels in the scheme `vN.N.N`, for instance `v1.0.0`, `v1.1.0` and `v2.0.0`, as well as `patch` and `backport`. Use release labels to target an issue or a PR for a given release. See [MAINTAINERS](MAINTAINERS.md#triage-open-issues) for more information on triaging issues. - -The release process is standard across repositories in this open-source project and is run by a release manager volunteering from amongst the [maintainers](MAINTAINERS.md). - -**Request For Comments (RFC)** - This should only be applied to RFCs. These are automatically applied to the RFCs when they are published. - -**META** - This will serve as a tracker for a set of tasks or sub-issues for a larger project. - - - diff --git a/NOTICE b/NOTICE index dda09663..c07ec469 100644 --- a/NOTICE +++ b/NOTICE @@ -1,3 +1,7 @@ +Apache Solr Benchmark +Copyright 2026 The Apache Software Foundation, Solr PMC + +This product includes software developed by the OpenSearch Contributors. OpenSearch Copyright 2022 OpenSearch Contributors diff --git a/RELEASE_GUIDE.md b/RELEASE_GUIDE.md deleted file mode 100644 index 8b8b87d4..00000000 --- a/RELEASE_GUIDE.md +++ /dev/null @@ -1,140 +0,0 @@ -# SOP: OpenSearch Benchmark Release Guide - -## Table of Contents -- [Overview](#overview) -- [Branches](#branches) - - [Releasing Branches](#release-branches) - - [Feature Branches](#feature-branches) -- [Release Labels](#release-labels) -- [Prerequisites](#prerequisites) -- [Release the new version of OpenSearch Benchmark to PyPI, Docker, and ECR](#release-the-new-version-of-opensearch-benchmark-to-pypi-docker-and-ecr) -- [Error Handling](#error-handling) - -## Overview -This document explains the release strategy for artifacts in this project. - -## Branches - -### Release Branches - -OpenSearch Benchmark follows the [semantic versioning convention](https://opensearch.org/blog/what-is-semver/). Currently, the project maintains the following active branches. - -* **main**: The mainline branch where most development occurs and changes get merged in. -* **1.0**, **1.1**, **1.12**, etc.: These are branches associated with released minor versions in the OSB 1.0 major version line, such as `1.0.0`, `1.1.0` and `1.12.0`. In between minor releases, there may be occasional patch releases such as `1.9.1`, which like version `1.9.0` would also be released off the `1.9` branch. -* **2.0**: The branch associated with the next major version line of OSB, which is yet to be released. - -Label PRs that you believe need to be backported with the target branch, such as `1.9` or `1.x`. Backport PRs by checking out the versioned branch, cherry-picking changes and opening a PR against each target backport branch. - -### Feature Branches - -In general, branches in the authoritative repository are intended for the various versions of the project. Do not create feature branches, the exception being long-lived branches that require active collaboration from multiple developers. Name such branches `feature/<FEATURE>`. Once the feature branch is merged into `main`, please make sure the feature branch is deleted. - -## Release Labels - -Releases are tagged with labels in the scheme `vN.N.N`, for instance `v1.0.0`, `v1.1.0` and `v2.0.0`, as well as `patch` and `backport`. Use release labels to target an issue or a PR for a given release. See [MAINTAINERS](MAINTAINERS.md#triage-open-issues) for more information on triaging issues. - -The release process is standard across repositories in this open-source project and is run by a release manager volunteering from amongst the [maintainers](MAINTAINERS.md). - -## Backport PRs -Add backport labels to PRs and commits so that changes can be added to `main` branch and other related major and minor version branches. For example, if a PR is published as a patch fix for OSB version 1.3.0, it should be labeled with a backport label called `backport-1.3` so that it backports to `1.3` branch. - -## Prerequisites - -* Since releases are generally published on Thursdays, maintainers should try to ensure all changes are merged in by Tuesday. -* A week prior to the scheduled release, maintainers should announce the fact in the [#performance channel](https://opensearch.slack.com/archives/C0516H8EJ7R) within the OpenSearch Slack community. -* Ensure that documentation is appropriately updated with respect to incoming changes prior to the release. - -## Release the new version of OpenSearch Benchmark to PyPI, Docker, and ECR - -1. Clone the official OpenSearch Benchmark git repository and change directory to it. This is where the following commands will be issued. - -2. Ensure that version.txt matches the new release version before proceeding. If not, open a PR that updates the version in version.txt and merge it in before proceeding with the following steps. For example, if OSB is currently at version `1.3.0` and we want to release the next version as `1.4.0`, update `version.txt` from `1.3.0` to `1.4.0`. - -3. Releases are published from a version branch, not directly from `main`. In the above example, we would create the `1.4` branch and switch to it. For patch releases, such as `1.3.1`, the `1.3` branch will already exist and does not need to be created. - -4. Create a tag for the `1.4.0` release. -``` - git tag 1.4.0 1.4 -``` - -5. Push the tag. This starts a workflow in Jenkins and creates an automated issue in the OSB repository. The issue needs to be commented on by a maintainer of the repository for the release process to proceed. The workflow uploads OSB to PyPI and OSB Docker Hub Staging account. Once the workflows are finished publishing OSB to PyPI and OSB Docker Hub staging account, the maintainer who pushed the tag should visit both PyPI and Docker Hub staging to perform the following steps to verify [...] - -``` - git push origin 1.4.0 -``` - -6. Check the progress of release here in the Jenkins console:: https://build.ci.opensearch.org/job/opensearch-benchmark-release/ - 1. For a more detailed look at what's happening, you can take the Build ID (which is the number highlighted in blue beneath "Stage View") and substitute it into this URL: https://build.ci.opensearch.org/blue/organizations/jenkins/opensearch-benchmark-release/detail/opensearch-benchmark-release/<Build ID>/pipeline/ - 2. If failed, inspect the logs. - -7. Verify PyPI: - 1. Download the OSB distribution build from PyPI: https://pypi.org/project/opensearch-benchmark/#files. This is a `wheel` file with the extension `.whl`. - 2. Install it with `pip install`. - 3. Run `opensearch-benchmark --version` to ensure that it is the correct version - 4. Run `opensearch-benchmark --help` - 5. Run `opensearch-benchmark list workloads` - 6. Run a basic workload on Linux and MacOS: `opensearch-benchmark run --workload pmc --test-mode` - 7. If you are fastidious, you can check the installed source files at `` `python3 -m site --user-site`/osbenchmark `` to verify that a recent change is indeed present. - -8. Verify Docker Hub Staging OSB Image Works: - 1. The staging images are at https://hub.docker.com/r/opensearchstaging/opensearch-benchmark/tags. - 2. Pull the latest image: `docker pull opensearchstaging/opensearch-benchmark:<VERSION>` - 3. Check the version of OSB: `docker run opensearchstaging/opensearch-benchmark:<VERSION> —version` - 4. Run any other commands listed on the Docker Hub overview tab. - -9. Copy over the image from Docker Hub Staging to Docker Hub Production and ECR: Once you have verified that PyPI and Docker Hub staging image works, contact Admin team member. Admin team member will help promote the “copy-over” workflow, where Jenkins copies the Docker image from Docker Hub staging account to both Docker Hub prod account and ECR. - 1. Admin will need to invoke the copy-over four times: - 1. repository: opensearchstaging, image: opensearch-benchmark:<VERSION> → repository: opensearchproject, image: opensearch-benchmark:<VERSION> - 2. repository: opensearchstaging, image: opensearch-benchmark:<VERSION> → repository: opensearchproject, image: opensearch-benchmark:latest - 3. repository: opensearchstaging, image: opensearch-benchmark:<VERSION> → repository: public.ecr.aws/opensearchproject, image: opensearch-benchmark:<VERSION> - 4. repository: opensearchstaging, image: opensearch-benchmark:<VERSION> → repository: public.ecr.aws/opensearchproject, image: opensearch-benchmark:latest - -10. See if OpenSearch-Benchmark Tags is Published: - 1. Check that the version appears in GitHub (https://github.com/opensearch-project/opensearch-benchmark/releases) and is marked as the “latest” release. There should be an associated changelog as well. Clicking on the “Tags” tab should indicate the version number is one of the project’s tags and its timestamp should match that of the last commit. If there was an error that prevented the release from being published, but this was fixed manually, click on the edit button (pencil ico [...] - 2. Check Docker Hub Production: https://hub.docker.com/r/opensearchproject/opensearch-benchmark. Both “latest” and the published release should appear on the page along with the appropriate publication timestamp. - 3. Check ECR: https://gallery.ecr.aws/opensearchproject/opensearch-benchmark. The dropdown box at the top should list both “latest” and the published release as entries. The publication time is also indicated. - -11. Notify the Community: Create a message that introduces the newly released OpenSearch Benchmark version and includes a brief summary of changes, enhanacements, and bug fixes in the new version. The message may look something like the following: -``` -@here OpenSearch Benchmark (OSB) 1.2.0 has just been released! - -What’s changed? - * Read here: https://github.com/opensearch-project/opensearch-benchmark/releases/tag/1.2.0 - * Documentation: https://opensearch.org/docs/latest/benchmark -Wow! Where can I get this? - * PyPI: https://pypi.org/project/opensearch-benchmark - * Docker Hub: https://hub.docker.com/r/opensearchproject/opensearch-benchmark/tags - * ECR: https://gallery.ecr.aws/opensearchproject/opensearch-benchmark -``` - -Send this message in the following channels in OpenSearch Community Slack: -* [#performance](https://opensearch.slack.com/archives/C0516H8EJ7R) - - -12. Ensure that we backport changes to other version branches as needed. See the guide for more information. - 1. Unless you released a major version, update main branch’s `version.txt` to the next minor version. For instance, if `1.1.0` was just released, the file in the `main` branch should be updated to `1.2.0`. - 2. Update the `version.txt` in the branch for the version that was just released with the current version but patch version incremented. For instance, if 1.1.0 was just released, the file in the `1.1` branch should be updated to `1.1.1`. - 3. Previous minor version is now stale - 4. For patch releases only: Ensure that the `main` branch will not need to have its version.txt updated since it's already pointing to the nexts major version. However, the branch with the major and minor version should have its `version.txt` file updated. For example, if `1.3.1` patch was just released, we'll need to visit the `1.3` branch and update the `version.txt` file to now point to `1.3.2`. However, we won't need to update `version.txt` in `main` branch since it's already poi [...] - -## Error Handling - -### Restarting the Release Process after an Error - -If an error occurs during build process and you need to retrigger the workflow, do the following: - -* Delete the tag locally: `git tag -d <VERSION>` -* Delete the tag on GitHub: `git push --delete origin <VERSION>` -* Delete the draft release on GitHub -* Create the tag again and push it to re-initiate the release process. - - -### Rename a tag - -If you published an incorrect tag name, then follow these steps: - -1. Run `git tag new_tag_name old_tag_name` to move old tag references to new tag alias -2. Run `git tag -d old_tag_name` to delete old tag locally -3. Ensure your remote is correct with `git remote -v`. Run `git push origin :refs/tags/old_tag_name` to remove old tag references in remote repository -4. Run `git push origin --tags` to make remote tags look like local tags -5. Verify that the release draft is pointing to the new tag \ No newline at end of file diff --git a/THIRD_PARTY.txt b/THIRD_PARTY.txt deleted file mode 100644 index a78dda28..00000000 --- a/THIRD_PARTY.txt +++ /dev/null @@ -1,9 +0,0 @@ - -OpenSearch Benchmark includes the following third-party software: - -This program, "pbzip2" is copyright (C) 2003-2011 Jeff Gilchrist. -All rights reserved. - -The library "libbzip2" which pbzip2 uses, is copyright -(C) 1996-2019 Julian R Seward. All rights reserved. - diff --git a/TRIAGE.md b/TRIAGE.md deleted file mode 100644 index 9e633188..00000000 --- a/TRIAGE.md +++ /dev/null @@ -1,68 +0,0 @@ -## Table of Contents -- [Scope](#scope) -- [Schedule](#schedule) -- [What Is Triaging](#what-is-triaging) -- [How to Triage](#how-to-triage) - -## Scope -These guidelines serve as a primary document for triaging issues in [opensearch-benchmark](https://github.com/opensearch-project/opensearch-benchmark) and [opensearch-benchmark-workloads](https://github.com/opensearch-project/opensearch-benchmark-workloads) project. For maintainers/contributors, it is a guide to ensure that we address all customer issues and address feature requests in a timely manner. - -## Schedule -Every week a maintainer will be assigned on a rotational basis to conduct triage meeting. -The meeting duration will be no more than 1 hour every Tuesday @1.30 PM PDT/3.30 PM CDT - -## What is Triaging -Triage is a process of grooming issues with correct labels, assigning them owners if available, ensuring that the issues have all the required information so that they are actionable - -## How to Triage -The steps listed below are not exhaustive and can be updated. Start with [opensearch-benchmark](https://github.com/opensearch-project/opensearch-benchmark) followed by [opensearch-benchmark-workloads](https://github.com/opensearch-project/opensearch-benchmark-workloads) project. For each of these projects we can follow the below steps to triage issues from different categories. Try to cover at least 1 issue from each of the below listed category. Note that there could be an overlap of i [...] - -### Steps to triage [opensearch-benchmark](https://github.com/opensearch-project/opensearch-benchmark) -- [Untriaged](https://github.com/opensearch-project/opensearch-benchmark/issues?q=is%3Aopen+is%3Aissue+no%3Alabel) - - The link above points to a triage issue, which in turn, contains a link to an editable document. This is used to keep track of the point where the last triage session held off, with regard to bugs, issues and enhancements. At the end of the current session, update the document appropriately. - - First check if any of the untriaged issue is a duplicate. If yes, then comment the duplicate issue link and close the duplicate - - Assign appropriate labels for these issues such as bug, enhancements, breaking etc. - - If possible assign owners who could be [SME](https://en.wikipedia.org/wiki/Subject-matter_expert) for the issue or volunteers if any - -- [High Priority](https://github.com/opensearch-project/opensearch-benchmark/issues?q=is%3Aopen+is%3Aissue+label%3A%22High+Priority%22) - - Search for issues labeled as High Priority. - - Ensure they have a status update or an owner - -- [Breaking](https://github.com/opensearch-project/opensearch-benchmark/issues?q=is%3Aopen+is%3Aissue+label%3Abreaking) - - Search for issues which are labeled as breaking - - Try to assign owners if it is a high priority beaking change - -- [Bugs](https://github.com/opensearch-project/opensearch-benchmark/issues?q=is%3Aissue+is%3Aopen+label%3Abug) - - Search for issues which are labeled as bugs - - Comment with a status update such as In Progress, Not Planned, Needs more information - -- [Enhancements](https://github.com/opensearch-project/opensearch-benchmark/issues?q=is%3Aissue+is%3Aopen+sort%3Acreated-desc+label%3Aenhancement+) - - Search for issues which are feature requests/enhancements - - Comment with a status update and assign owners if it is going to be the next release candidate - -- [Documentation](https://github.com/opensearch-project/opensearch-benchmark/issues?q=is%3Aopen+is%3Aissue+label%3Adocumentation) - - These issues although not breaking are important for better customer experience - - Feel free to encourage the requester to raise a PR, these can be tagged as good first issue as well - -### Steps to triage [opensearch-benchmark-workloads](https://github.com/opensearch-project/opensearch-benchmark-workloads) -- [Untriaged](https://github.com/opensearch-project/opensearch-benchmark-workloads/issues?q=is%3Aopen+is%3Aissue+no%3Alabel) - - First check if any of the untriaged issue is a duplicate. If yes, then comment the duplicate issue link and close the duplicate - - Assign appropriate labels for these issues such as bug, enhancements, breaking etc. - - If possible assign owners who could be [SME](https://en.wikipedia.org/wiki/Subject-matter_expert) for the issue or volunteers if any - -- [Breaking](https://github.com/opensearch-project/opensearch-benchmark-workloads/issues?q=is%3Aopen+is%3Aissue+label%3Abreaking) - - Search for issues which are labeled as breaking - - Try to assign owners if it is a high priority beaking change - -- [Bugs](https://github.com/opensearch-project/opensearch-benchmark-workloads/issues?q=is%3Aopen+is%3Aissue+label%3Abug) - - Search for issues which are labeled as bugs - - Comment with a status update such as In Progress, Not Planned, Needs more information - -- [Enhancement](https://github.com/opensearch-project/opensearch-benchmark-workloads/issues?q=is%3Aopen+is%3Aissue+label%3Aenhancement) - - Search for issues which are feature requests/enhancements - - Comment with a status update and assign owners if it is going to be the next release candidate - -- [Documentation](https://github.com/opensearch-project/opensearch-benchmark-workloads/issues?q=is%3Aopen+is%3Aissue+label%3Adocumentation) - - These issues although not breaking are important for better customer experience - - Feel free to encourage the requester to raise a PR, these can be tagged as good first issue as well - diff --git a/create-notice.sh b/create-notice.sh index 9c539878..7504e2f5 100755 --- a/create-notice.sh +++ b/create-notice.sh @@ -42,42 +42,33 @@ function main { # link to a URL providing the MPL-covered source code printf "The source code can be obtained at https://github.com/certifi/python-certifi\n"; >> "${OUTPUT_FILE}" add_license "certifi" "https://raw.githubusercontent.com/certifi/python-certifi/master/LICENSE"; - add_license "elasticsearch" "https://raw.githubusercontent.com/elastic/elasticsearch-py/master/LICENSE"; + add_license "pysolr" "https://raw.githubusercontent.com/django-haystack/pysolr/master/LICENSE"; + add_license "requests" "https://raw.githubusercontent.com/psf/requests/main/LICENSE"; add_license "jinja2" "https://raw.githubusercontent.com/pallets/jinja/master/LICENSE.rst"; add_license "jsonschema" "https://raw.githubusercontent.com/Julian/jsonschema/main/COPYING"; add_license "psutil" "https://raw.githubusercontent.com/giampaolo/psutil/master/LICENSE"; add_license "py-cpuinfo" "https://raw.githubusercontent.com/workhorsy/py-cpuinfo/master/LICENSE"; - add_license "tabulate" "https://bitbucket.org/astanin/python-tabulate/raw/03182bf9b8a2becbc54d17aa7e3e7dfed072c5f5/LICENSE"; + add_license "tabulate" "https://raw.githubusercontent.com/astanin/python-tabulate/master/LICENSE"; add_license "thespian" "https://raw.githubusercontent.com/kquick/Thespian/master/LICENSE.txt"; add_license "boto3" "https://raw.githubusercontent.com/boto/boto3/develop/LICENSE"; add_license "yappi" "https://raw.githubusercontent.com/sumerc/yappi/master/LICENSE"; add_license "ijson" "https://raw.githubusercontent.com/ICRAR/ijson/master/LICENSE.txt"; add_license "google-resumable-media" "https://raw.githubusercontent.com/googleapis/google-resumable-media-python/master/LICENSE"; add_license "google-auth" "https://raw.githubusercontent.com/googleapis/google-auth-library-python/master/LICENSE"; - add_license "aiokafka" "https://raw.githubusercontent.com/aio-libs/aiokafka/master/LICENSE"; # transitive dependencies # Jinja2 dependencies add_license "Markupsafe" "https://raw.githubusercontent.com/pallets/markupsafe/master/LICENSE.rst"; - # elasticsearch dependencies - add_license "urllib3" "https://raw.githubusercontent.com/shazow/urllib3/master/LICENSE.txt"; - #elasticsearch[async] dependencies - add_license "aiohttp" "https://raw.githubusercontent.com/aio-libs/aiohttp/master/LICENSE.txt"; - #aiohttp dependencies - add_license "async_timeout" "https://raw.githubusercontent.com/aio-libs/async-timeout/master/LICENSE"; - add_license "attrs" "https://raw.githubusercontent.com/python-attrs/attrs/master/LICENSE"; - add_license "chardet" "https://raw.githubusercontent.com/chardet/chardet/master/LICENSE"; - add_license "multidict" "https://raw.githubusercontent.com/aio-libs/multidict/master/LICENSE"; - add_license "yarl" "https://raw.githubusercontent.com/aio-libs/yarl/master/LICENSE"; - # yarl dependencies + # requests dependencies + add_license "urllib3" "https://raw.githubusercontent.com/urllib3/urllib3/main/LICENSE.txt"; + add_license "charset-normalizer" "https://raw.githubusercontent.com/Ousret/charset_normalizer/master/LICENSE"; add_license "idna" "https://raw.githubusercontent.com/kjd/idna/master/LICENSE.md"; - # yarl dependency "multidict" is already coverered above # boto3 dependencies add_license "s3transfer" "https://raw.githubusercontent.com/boto/s3transfer/develop/LICENSE.txt"; add_license "jmespath" "https://raw.githubusercontent.com/jmespath/jmespath.py/develop/LICENSE.txt"; add_license "botocore" "https://raw.githubusercontent.com/boto/botocore/develop/LICENSE.txt"; # google-resumable-media dependencies - add_license "google-crc32c": "https://raw.githubusercontent.com/googleapis/python-crc32c/master/LICENSE"; + add_license "google-crc32c" "https://raw.githubusercontent.com/googleapis/python-crc32c/master/LICENSE"; } main diff --git a/version.txt b/version.txt index ccbccc3d..6e8bf73a 100644 --- a/version.txt +++ b/version.txt @@ -1 +1 @@ -2.2.0 +0.1.0
