message has been deleted

oh, dear, I'll try again...

There's also a difference between a well-specified issue and a request for debugging someone's setup

(Just complaining more about k8s terrible signal:noise from their stale bot)

We can also consolidate old issues or move them to a list somewhere else. Like if we have a bunch of edge-case REAPI issues that we don't have the ability to investigate, we can make a big issue for that and close the sub-issues

https://github.com/actions/stale Example: Boatload of options

https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#merge_group seems to be its own event, so maybe it does have different secret rules to the

pull_request

event

What about Nailgun? Doesn't that initialize a pool on each scheduler initialization? Not sure how long that takes though

Disabling nailgun was a huge speedup for CI at $work, like a minute per PR in total.

Same, we've also disabled it in CI

We could also add a step to CI to first run --changed-since and then run the whole battery. So we can see how many issues would have snuck through the cracks

Could it in theory infer which backends are relevant for a change using the existing dependency inference?

Recapping, for changed-since, I think we mentioned 2 simple action items: • Run --changed-since first and then the full battery • Try sharding by backend (maybe manually) to increase locality of tests And then some other changes that we need to look into: • Merge queues could let us run integration tests for multiple merges • We could identify which backends are affected and only run those

Sample PRs https://github.com/pantsbuild/pants/pulls?q=is%3Apr+%22%5Bcall-by-name%5D%22+is%3Aclosed+

It was good to see you all, but my internet has apparently dropped out so that's it for me today 👋 (someone else will have to take notes 🙂)

bad mic, just here to learn more

👋