Plan for triaging semver-minor backports in LTS meetings

[gibfahn]

I'm not sure what the existing process is, but given the discussions around backporting and labelling (nodejs/node#12431), it might be worth trying to decide how we're going to triage semver-minor backport PRs.

Obviously this doesn't have to be set in stone, and it's more a note to self than anything else. If things are obviously wrong feel free to just edit this directly.

Strawman proposal:

Run branch-diff -g --filter-release --require-label=semver-minor --exclude-label=semver-major,meta,dont-land-on-v6.x,backport-requested-to-v6.x upstream/v6.10.3-proposal upstream/v7.x

For each PR we:

• add do-not-land-v6.x if we think it should not be backported (with a comment)
• add land-on-v6.x if we think it should be backported (will be replaced with cherry-picked-to-v6.x or backported-to-v6.x)
• leave lts-watch-v6.x if we want to leave it to bake for a while, and revisit later.

[jasnell]

to this point, the process has been to wait until we have a batch of semver-minor commits queued up, then we go through them to make sure there are no objections. Generally speaking, we've only backported semver-minor's into LTS on request -- that is, we only backport if there is a specific request to do so. I've seen nothing to convince me that that process should be changed. Going through all of the potential semver-minor's that could land is not a great use of time.

[gibfahn]

Agreed at meetings, note that we have the baking-for-lts label now to cover things that are baking.