Limit push access to LTS staging branches to backport team

[MylesBorins]

This came up in the first backport team meeting. One way that we can be sure of the health of the staging branch is to make sure only backport-team is pushing to it.

Any objections?

[gibfahn]

In my experience people pushing to the wrong branches is nearly always a mistake, anything that makes it harder for me to accidentally push to the wrong branch SGTM.

[refack]

I call for a more radical solution: clone into a separate repo.
This will allow fine grained control of access. And in term of workflow it's as simple as changing a word in the git command line.
Main question is where issues and PR are managed:

1. stay in node with the managed by appropriate labels
2. move here with better focus and more accurate distribution list

[bnoordhuis]

I call for a more radical solution: clone into a separate repo.

Intensely annoying for code archeology, something I do a lot.

[gibfahn]

I call for a more radical solution: clone into a separate repo.
This will allow fine grained control of access. And in term of workflow it's as simple as changing a word in the git command line.

That seems like it'll make everything much more complicated for no obvious benefit.

If we limit access to the branch then if you push to it by mistake it'll just be rejected, and you'll realise your mistake. That seems like the ideal way to do it.

Having a separate repo loses us many of the benefits of Git, it means you need two clones of Node (doubles your disk usage), and that you can no longer just git cherry-pick HASH to backport.

This will allow fine grained control of access.

Protecting the branches should allow equally fine-grained access control?

And in term of workflow it's as simple as changing a word in the git command line.

You mean for the clone? Yeah sure, it's only slightly more complicated for that, but that's something you do once. In terms of backporting it will make it much more complex.

EDIT: In fact what would probably happen is everyone would just have nodejs/lts and nodejs/node as two remotes of the same repo, which leads to what is in essence the same as having protected branches.

[refack]

Think about it again.
Clone the repo, not start from commit 0.

@bnoordhuis

Intensely annoying for code archeology, something I do a lot.

I agree that archaeology is very useful, I use is allot as well to try and figure out what led to a certain solution.
But I don't think we'll lose that, it'll be the same repo just under a different name. Only thing we'd "lose" is issue number parity, but since we put full URLs in commit messages, we won't really lose that.

@gibfahn

Having a separate repo loses us many of the benefits of Git, it means you need two clones of Node (doubles your disk usage), and that you can no longer just git cherry-pick HASH to backport.

No, you probably already use "two" remote repos, your fork, and the upstream one? it's just a matter of where you target your push/pull

EDIT: In fact what would probably happen is everyone would just have nodejs/lts and nodejs/node as two remotes of the same repo, which leads to what is in essence the same as having protected branches.

Exactly! except not "everyone" will have these two, only people who do backporting. And it will allow better management for issues/PRs and a better focused notification audience.

[refack]

Another benefit I tought of:

1. If we remove the backporting branches from the main repo git will be more responsive locally (we don't want to get to the chromium situation, where git status take ~2 minutes)

What I've seen in places that did this sort of split was a conceptual change in the way the devs thought. When it's unnecessary vNext was freed from backward compatibility. While vLTS got dedicated dev resources to solve version specific issues in the right context.

An example nodejs/node#12580: whatever the eventual solution will be, IMHO this is a v7 issue and should have been solved with v7 as the focus, and not as a v7 follows master solution.

[refack]

This ties in with my thoughts that we should invest in vLTS more #203 (comment)

[gibfahn]

If we remove the backporting branches from the main repo git will be more responsive locally (we don't want to get to the chromium situation, where git status take ~2 minutes)

Is it the number of branches that makes git take a long time? I thought it was the lstat on all the files. It's certainly pretty quick right now: git status 0.04s user 0.09s system 168% cpu 0.074 total.

Exactly! except not "everyone" will have these two, only people who do backporting. And it will allow better management for issues/PRs and a better focused notification audience.

Everyone who commits into master should (hopefully) backport it to the relevant release lines if there is a merge conflict, so realistically most contributors will need both (so you won't get much git status benefit). You want the original committer to fix any backport merge conflicts because they should be the person who best understands the change.

What I've seen in places that did this sort of split was a conceptual change in the way the devs thought. When it's unnecessary vNext was freed from backward compatibility. While vLTS got dedicated dev resources to solve version specific issues in the right context.

The whole backporting/release process is designed to minimise differences between versions, and to minimise mental load about which commits are where. Where possible we change things in master, and where possible we backport to all active release lines. When it's time for a new release we can just branch from master (or vNext). What I'd like to do is have less difference between different versions of Node (i.e. backport more stuff), and I don't see how this would help that.

An example nodejs/node#12580: whatever the eventual solution will be, IMHO this is a v7 issue and should have been solved with v7 as the focus, and not as a v7 follows master solution.

I think nodejs/node#12580 is something that's relevant to Node 8 as much as Node 7. --debug had to be dropped without deprecation cycles because of v8, but --inspect --debug-brk existed before --inspect-brk, and there's no reason to just remove that at the same time.

[refack]

Is it the number of branches that makes git take a long time? I thought it was the lstat on all the files. It's certainly pretty quick right now: git status 0.04s user 0.09s system 168% cpu 0.074 total.

For git status probably, but for git diff, git commit, and git log the refs are opened (not to mention git blame)... But I agree that marginal.

Everyone who commits into master should (hopefully) backport it to the relevant release lines if there is a merge conflict, so realistically most contributors will need both (so you won't get much git status benefit). You want the original committer to fix any backport merge conflicts because they should be the person who best understands the change.

The point is that most of the things should not be backported. Main use-case for master is new development.

The whole backporting/release process is designed to minimise differences between versions, and to minimise mental load about which commits are where. Where possible we change things in master, and where possible we backport to all active release lines. When it's time for a new release we can just branch from master (or vNext). What I'd like to do is have less difference between different versions of Node (i.e. backport more stuff), and I don't see how this would help that.

I think this is the crux of the matter; I'd like to see more difference between versions 😉. More innovation in vNext / more stability in vLTS, and you are right my suggestion will help that.
Otherwise why have semver-major version changes at all?

[gibfahn]

The point is that most of the things should not be backported. Main use-case for master is new development.

Most Node.js development is minor and patch stuff, if it doesn't go to master, where should it go?

I think this is the crux of the matter; I'd like to see more difference between versions

You'd like to see more major changes, or less minor/patch backporting? The former is limited by the mass of existing Node.js code, the developers of which are (understandably) unwilling to have to change every year, and not by the backporting process. The latter is facilitated by the current model, and I'm not really sure why you wouldn't want things to be backported.

The point of semver is to allow backporting without affecting stability, and it's worked pretty well so far. A Node.js developer wants existing APIs not to break, and new APIs to work across every version of Node his app/library is likely to have to run on. What we currently do is tailored around that.

[gibfahn]

Anyway, splitting into multiple repos is orthogonal to this, so probably worth discussing in a separate issue.

[MylesBorins]

I'm a huge -1 on a new repo. Distributed nature of git aside it is project history, and it belongs in the repo.

I believe that outstanding questions tangential to the private branches can be discussed in other issues. I think we should decide as a WG that we want to vote on this in tomorrows meeting. Assuming we vote to move forward we should bring to ctc Wednesday.

[refack]

As an outsider I think I'm +1 on limited access branches

[jasnell]

I'm +1 to limiting access to the staging and release LTS branches to the LTS WG. (that said, if we're goiing to pursue this, we should formalize the LTS WG... and I'm thinking it makes sense to formally attach it to the Release team in some way...)