doc: clarify who may land on an LTS staging branch

[MylesBorins]

Current language is a bit confusing

Refs: #24344 (comment)

[nodejs-github-bot]

@MylesBorins sadly an error occured when I tried to trigger a build :(

[targos]

This paragraph is part of "How are LTS Branches Managed?" so it doesn't really make sense to have a rule about non-LTS branches in it IMHO.

[MylesBorins]

@targos I'm trying to figure out the intention of the original language as compared to what is documented in https://github.com/nodejs/release#lts-staging-branches

Perhaps it is better to just point at the Release repo as the source of truth?

[refack]

I read the same semantics in https://github.com/nodejs/release#lts-staging-branches

Every LTS major version has two branches in the GitHub repository: a release branch and a staging branch. The release branch is used to cut new releases. Only members of the release team should land commits into the release branch. The staging branch is used to land cherry-picked or backported commits from master that need to be included in a future release.

[MylesBorins]

@refack independent of the specific reading of the text this is how the LTS team has operated... otherwise there would be no need or an @nodejs/backporters team.

The only reason the branches are not protected are because they can't be force pushed

--> nodejs/Release#209

If we want to make the policy more lenient that is fine, but a different conversation. If the current way the policy is documented is confusing, we should fix that.

There have been more than one occasion where collaborators have accidentally backported stuff to the staging branch and it has been pointed out and not an issue. This is the first time it became clear that the documentation was inconsistent, or could be read as inconsistent, with how we actually do the work.

[Trott]

LGTM in that this clearly documents our current practice and is more clear (I think) than the current text. Whether that practice could or should be changed, or whether the documentation could or should happen elsewhere rather than in this particular paragraph...
¯\(ツ)/¯

[targos]

Then can this also mention the backporters team for LTS staging? I didn't know it's purpose until now

[MylesBorins]

I've further clarified the language PTAL

[richardlau]

@targos I'm trying to figure out the intention of the original language as compared to what is documented in https://github.com/nodejs/release#lts-staging-branches

Perhaps it is better to just point at the Release repo as the source of truth?

IMO https://github.com/nodejs/release#lts-staging-branches has the same issue as the collaborator guide before the changes in this PR:

Every LTS major version has two branches in the GitHub repository: a release branch and a staging branch. The release branch is used to cut new releases. Only members of the release team should land commits into the release branch. The staging branch is used to land cherry-picked or backported commits from master that need to be included in a future release.

So having defined "release branch" and "staging branch" the only documented restriction is on the "release branch" -- If both branches are to be restricted then why specify "release branch" in the third sentence?

[MylesBorins]

can we fast track this?

@richardlaunodejs/Release#387 should fix the inconsistency in the Relase repo and I've opened nodejs/Release#388 to discuss changing the policy

[jasnell]

into LTS staging branches.

[mhdawson]

LGTM as documenting current practice

[MylesBorins]

CI: https://ci.nodejs.org/job/node-test-commit/23474/

[danbev]

Landed in e9545e6.