[FEATURE] Improve Backporting Experience for Developers

[IanHoang]

Is your feature request related to a problem?

Previously, we've had situations where a change was improperly backported or is missing from a branch and requires manual intervention.

@OVI3D0 brought up a good question on how to determine which branch a change should be backported to. There is information on this in CONTRIBUTING.md but it only details on how to backport but not when developers should. In order to know when a change should be applied to other branches, developers need to understand what kind of change they are proposing in the PR (i.e. is it focused on formatting, adding a new API, etc.). For example, a proposed API change might only be supported in newer versions like OS 1 and 2 but not ES 7 and thus the change should only be backported to OS 1 and 2 from main.

What solution would you like?

• We should add more details to the contribution guide on what kinds of changes should be backported
• Consider an automation that can be baked into the Pull Request and recommends users which labels this should have. This automation could leverage doing a git diff between branches' files.

This issue serves as an open discussion on what should be done to streamline the developer experience and reduce the amount of issues related to improper backports.

[dblock]

In 3.0 we are discussing not needing to backport anymore.

cc: @andrross

[andrross]

In 3.0 we are discussing not needing to backport anymore.

cc: @andrross

We have a proposal to simplify the branching strategy for the OpenSearch distribution to eliminate many backports. OSB has its own branching strategy/release cycle so it might be able to make a similar simplification.

[IanHoang]

Thanks for linking the proposal @andrross @dblock. OSB repository currently uses suggestions from the linked proposal but the OSB workloads repository still requires backporting to several branches since each branch contains workloads specific ES and OS major version.