Wpt: In-Flight & Stale Branches

[snuggs]

Migrated from https://github.com/tmpvar/jsdom/issues/2033

Basic info:

_Apologize in advance as did not know where to place this_. Upon updating a repo on an old laptop that had an outdated master I received the following branch updates. What is our strategy for dealing with this because the number of branches is much larger than the last time the machine pulled within the same time frame. Feel free to close immediately. But in NYC our motto is "If you see something...say something."

Please advise...

Solution:

A poor-person's solution would be just to encourage branch deletion from the PR authors at minimum. Encouragement to reviewers at medium. Stale branch deletion procedure at maximum.

[foolip]

That chromium-export branches are left around is a known problem, https://bugs.chromium.org/p/chromium/issues/detail?id=750942 and maybe other bugs.

@Hexcles, for chromium-export-* PRs in general, maybe we should close the PRs if they've been inactive for some amount of time? A new one should be auto-created as soon as the exporter needs it, right? Although, I guess without further tweaks it'd be recreated just minutes later...

What are all of these untagged-* tags, does anyone know?

As for all of the other branches sitting around, what should the logic be for automatically deleting them? At minimum, I think we can delete anything where merging the branch into origin/master succeeds and results in no diff against origin/master. But that'll leave lots of things that have been merged but now conflicts.

[jgraham]

The untagged-* tags are auto-created by GitHub because we upload the manifest and GitHub associates a tag with every download. I created a PR to at least make the tag name more meaningful although other solutions are possible like not using GitHub for storing the manifests.

[snuggs]

@jgraham @foolip thanks for addressing! Not a blocker for me of course. But they tell us on the train in NYC "If you see something, say something!" so I did. :-) I noticed the label priority:backlog What is the next step? Don't want to be the "what's the status" guy 6 months from now. Pardon, as I am new to the process.

Happy Sunday

[foolip]

@jgraham could we have a separate repo for manifests where we just have folders for each wpt sha and put the manifests inside?

@snuggs, the priority labels are used by the ecoystem infra rotation for wpt issues with the infra label. Backlog means "This is out of scope for the time-being. (Driving down the number of such issues may become part of P3 OKRs.)"

But now that @jgraham has told me where those tags from and I know they'll keep growing at a fast pace, I'll make this roadmap instead, so that we come back to it regularly.

[Hexcles]

@snuggs Thanks for being proactive!

@foolip 's pointer is correct. That is the only bug remaining now that produces stale branches. (The implication: there used to be some other bugs, which should be all fixed and I've done some housekeeping to manually remove stale branches left from the bugs.) In a normal export process, the branch is immediately deleted after it is merged into master.

For the Chromium exporter, it really is about the PRs. Deleting branches without abandoning PRs would be confusing. For starters, it is safe to close PRs when the corresponding CLs are abandoned. Other scenarios may be slightly trickier (e.g. WPT changes removed from a CL, open CLs without activities for a long time, etc.).

[snuggs]

@Hexcles no worries that's what i'm here for.

FWIW may not be so much of a fire for WPT but the users of JSDOM are experiencing this as well merely from WPT being a bonafied submodule of JSDOM. This is where I experienced this in the first place and was a red herring until I was told the culprit was wpt and to bring issue here. A simple git fetch and 💥 .

https://github.com/tmpvar/jsdom/issues/2033

[Hexcles]

BTW, just wanted to add that a lot of the branches in the screenshot are not "stale" -- Chromium exporter creates PRs when a CL is still under review ("in-flight"), and we do have that many active in-flight CLs/PRs.

And regarding the "💥", I think the keypoint is to use git fetch -p. Due to our extensive use of branches, even if there were no stale branches, without -p the number of remote/ references would explode locally anyway. And as long as we use git fetch -p, the only downside I can think of is spamming everyone's terminal :) (Not sure about the submodule use case though.)

[snuggs]

¯\_(ツ)_/¯ @Hexcles you don't know what you don't know...But I learn fast!

A few points:

1. Updated title to In-Flight & Stale Branches
2. What's a "CL" and where can i get information on the process? I currently watch chromium builds for web components/link loading but not familiar with build process.
3. Thanks for the info on git-fetch -p. Just when I think I know git...
4. Have done the research on git submodule. Alls I can say is I see the words...having difficult to put together the sentences. :-) Hope you fair better than me. https://git-scm.com/docs/git-submodule#git-submodule---remote

[snuggs]

@Hexcles Here's our answer. I don't believe this effects user land. Only maintainers. Which perhaps is still a concern. You would know better than me sir.

[Hexcles]

You can think CL == commit. Essentially, Chromium exports every commit that contains WPT changes as a PR, which means a branch. We do delete that branch once it's merged, but that still means we are constantly creating and removing branches. Hence, git fetch -p is almost a must. Unfortunately, it seems submodule doesn't have that pruning feature.

I'm curious what the '💥' actually is, aside from spamming the terminal (and using a little more storage).

[foolip]

Absent complaints about serious side effects of this, I'm going to demote this from roadmap to backlog.

[snuggs]

Good call @foolip. As long as is documented that's the minimum we can do yes?

Have been working on jsdom a bit since last convo and some feedback, isn't thaaat painful from a contributor's side. Just on submodule updates. Which ATM are already out of date a tick.

[foolip]

Now documented by https://github.com/w3c/web-platform-tests/pull/8173. I also found https://stackoverflow.com/questions/18308535/automatic-prune-with-git-fetch-or-pull but am not sure we should recommend it, too much information isn't necessarily helpful.