Merge upstream up to 425d77f8124a50fc033e8fb3bdf7b89a6a25f4fa

[ClearlyClaire]

As explained in #2363 (comment), I find it easier to do the merge/port PRs myself. That being said, thanks @Plastikmensch for #2363, this has been (and will continue to be) helpful for triaging commits to port/skip/postpone

Conflicts

• .rubocop_todo.yml:
  Upstream regenerated this file, glitch-soc had a specific ignore.
• README.md:
  Upstream updated its README, but glitch-soc has a completely different one.
  Kept glitch-soc's README

Postponed changes:

• d4807a5 (link preview change, see Consider porting link preview card design changes from upstream #2343)
• 4c999a7 (link preview change, see Consider porting link preview card design changes from upstream #2343)
• 01f0cff (link preview change, see Consider porting link preview card design changes from upstream #2343)
• 2cbdff9 (role badges redesign, see Port upstream's role badge design #2341)
• 6308dca (UI focus change, see Port UI focus behavior/styling changes from upstream #2342)

Ported changes

• 71fd703

Skipped changes

• 4d3a129 (already fixed in Fix Public TL not indicating new toots when allowLocalOnly is enabled #2336)

[Plastikmensch]

As explained in #2363 (comment), I find it easier to do the merge/port PRs myself. That being said, thanks @Plastikmensch for #2363, this has been (and will continue to be) helpful for triaging commits to port/skip/postpone

Glad it was helpful :3
I could maintain a list (in an issue or so) of upstream commits which could be ported and which need to be postponed, if that's something that would help you.

One clarification question though: Does "port PRs" also mean porting already postponed changes?

[ClearlyClaire]

I could maintain a list (in an issue or so) of upstream commits which could be ported and which need to be postponed, if that's something that would help you.

It is useful! It's also very useful to point commits to already-open issues!

One clarification question though: Does "port PRs" also mean porting already postponed changes?

Yeah also, although it's a little more self-contained and so a little easier to maintain.

[Plastikmensch]

It is useful! It's also very useful to point commits to already-open issues!

Can do!
I'm a bit unsure if I should create one issue and keep updating it, or create a new one after every upstream merge.
(The latter would be a bit less spammy with references and keep the backreferences useful, but has the disadvantage of not really working well with partial merges)

Yeah also, although it's a little more self-contained and so a little easier to maintain.

Okay, then I'll probably stop doing those.