Daniel (dB.) Doubrovkine
Daniel (dB.) Doubrovkine
Dup of https://github.com/opensearch-project/OpenSearch/issues/2719? is that helpful at all? What's your configuration? Which version of OpenSearch are you using in AWS OpenSearch?
Would it make sense to extend rescoring to run on a higher level than shard (i.e. merge)? Another idea is that merge could be seen as any map/reduce, so rescore...
I like the idea of extensibility in this space. I feel like I'd want to write a super optimized parser (e.g. with native code, or rust), even for JSON, and...
cc: @elfisher
> It seems like the output of [danger-changelog](https://github.com/dblock/danger-changelog/blob/master/CHANGELOG.md) is not too dissimilar to the [existing release notes](https://github.com/opensearch-project/opensearch-build/blob/main/release-notes/opensearch-release-notes-1.2.0.md) (last good example - subsequent 1.2.x are all log4j fixes), except without the...
> Would there be an expectation as part of the code review to review the release notes in the PR as well? That might help with quality. Yes.
@peternied Why would we need that if every PR _must_ have a CHANGELOG entry?
@peternied We would adopt a standard, such as https://keepachangelog.com/en/1.0.0/
> Do we expect the `CHANGELOG` to have these groups pre-defined, that will allow authors/reviewers to add/review the CHANGELOG entry, added under the right group, along with every PR? Yes,...
@kartg I think we do simple: every PR requires a CHANGELOG update. Humans ensure quality in code reviews. Multiple commits can be merged in CHANGELOG as we make progress.