Visually, does this change look the same? Can you add before/after pictures like you did in D4839?

Now we're breaking them apart so the SWMansion icon pack can be "frozen," and we'll only add to the CommIcon pack in the future

In D4831#139757, @atul wrote:

(Another thing that'll be needed to bumped on each release)

Some questions before I can accept:

• How were you able to verify these icons didn't exist in the pack? The SWMansion icon pack has a reply-filled, cloud-filled, and sidebar-filled that are actively used in the codebase. I haven't seen the "subsequent diffs that "consume" the CommIcon component" but I'm assuming given that this diff exists we want to use these icons over the SWMansion icon pack ones going forward? Or is that interpretation wrong?
• What's the difference between icons from both packs? You said that the SWMansion icon pack didn't contain these icons, but I found instances of reply-filled, cloud-filled, and sidebar-filled in the SWMansion icon pack, so if the icons are different, showing photos with their differences would be helpful. Otherwise, if we already have reply-filled, cloud-filled, and sidebar-filled icons, why are we switching away?
• Minor, but comparing this diff to the current structure of the SWMansion icon pack in the codebase, there are some differences. For example, you wrote CommIcons.ttf whereas currently it's swmansion.ttf (all lowercase). Personally, I think CommIcons.ttf is better, especially looking at the rest of the Info.release.plist file which contains useful capitalization, but maybe the swmansion.ttf can be renamed to SWMansion.ttf or something. Or even include the word icons in it, like with CommIcons.ttf.

Makes sense

In D4816#139499, @jon wrote:

We're not talking about managing notifs, we're talking about managing your reviewers' queues.

For github, the notification feed https://github.com/notifications is the queue.

I think @ashoat may have hit Request Changes after submitting his comment but not before you replied here, which is why this diff is in a weird state of you answered his question but received no response and instead got a request for revision.

In D4824#139480, @ashoat wrote:

Seeing @abosh's screenshots in D4825 make me fear the answer is "yes". Please do not land something like this on master...

In D4825#139485, @ashoat wrote:

Based on @abosh's screenshots, it looks like this diff is attempting to land fake placeholder emojis on master...

Other than what @tomek said, this looks good. So if I understand correctly, threadInfo can now be null, undefined, or void, and in that case, we will return empty strings to InlineSidebar, since we still want to display the reactions but no text for a thread (since it doesn't exist)?

Tested this locally and it looks great! The visual change of the tooltip 'fading' through the message when holding down on the message is nice.

Adding @atul and @tomek as blocking to get at least one of them to review this.

Should link the relevant Linear issue in the diff summary whenever you put up a diff.

Accepting because we discussed this IRL. Also see this comment left by me for more context as to why ShellCheck was bumped to ubuntu-22.04.

Ah, investigated with @atul and figured out why this is happening. ShellCheck on lint-staged is installed by homebrew (locally, by developers), ShellCheck on Buildkite is installed using apt-get, and ShellCheck on GitHub Actions is preinstalled using ubuntu-latest. Because this check of using command -v over which is optional in versions of ShellCheck 0.7.1+ (which the homebrew and apt-get installations of ShellCheck are), this was not caught by those CI builds, but was caught by GitHub Actions since the version of ShellCheck on ubuntu-latest is 0.7.0, which is < 0.7.1. To fix this, we're bumping the ShellCheck job on GitHub Actions to run off ubuntu-22.04 instead of ubuntu-latest (which is 20.04). This is because the version of ShellCheck that comes with ubuntu-22.04 is 0.8.0-2, which is 0.7.1+.

What's more confusing to me is why this passed through lint-staged and Buildkite, but failed on GitHub Actions. They should be running the same shellcheck -x -P SCRIPTDIR [FILES...] command...

Actually just saw this on GitHub, was going to send you a message about it, and saw this diff! Thanks for catching this.

Still in the middle of reviving this but filtering out the header changes so the bulk CMake logic can be added.

I'll "Request Review" when this is in a better state

Thanks for addressing my feedback! Everything you said makes sense, so accepting.

welcoming feedback on how i can improve my summaries/test plans

I think it should be good after this!

In D4790#138445, @ashoat wrote:

To make the files visible to everybody, you'll need to "attach" them. @abosh has written some advice on how to do this before... @abosh, would you mind putting that info into a doc on Notion and then sharing it with @jon?

Also it seems your files are still "Restricted", because I can't see them even though they're in the summary.

Ran ShellCheck manually on the Bash code that was still stored in a string variable (like in better-prompt.nix and dev-shell.nix), and they had errors...I really think all shell code should be put into a .sh file so that at least you can have lint-staged or Buildkite lint them before reviewers have to take a look at it. I know it involves extra work on your end but it's more modular, cleaner to read, easier to review, and passes through our CI.

I continue to dislike this pattern of putting bash inline in .nix files, especially here where it fully circumvents Shellcheck. Is there any way to check in this bash to the repo as a .sh file? Any way at all?

Agree with @ashoat's assessment. If you can create a stack out of this diff so the depends-on relationship between Nix migration and this is more explicit that'd be cool, but not necessary.

Not sure, but I think we should add a section on the docs to tell the user how to install cmake-lint, because otherwise they won't be able to commit code that's matched by the cmake-lint glob in .lintstagedrc.js. Do we need pip to install cmake-lint?

Ok, bash-wise, looks good!

In D4773#137756, @atul wrote:

Was it something your IDE picked up on...or?

Ya

In D4772#137753, @atul wrote:

Looks good, but lets hold off on landing this until nix support gets landed

Don't think the test plan should be NA here, even if it may seem like a trivial change. How were you able to determine these #include directives were unused in the first place? Was it something your IDE picked up on...or?

Some small fixes here and there, then should be good to go!

Sent message.

Ok, will do.

In D4772#137561, @atul wrote:

Before I accept, could you send a message in the Comm Dev Team chat letting everyone know that they'll need to install shellcheck (and provide instructions on how they can go about doing that?)

Sure, that makes sense. Moved ShellCheck instructions up to the top of the Prerequisites section under Rust and above Yarn (to keep it "alphabetized"?). It's such a small command I doubt it should be an issue, but open to thoughts about where to place it in the doc.

Looks good to me! Accepting, but adding @ashoat and @atul as blocking as this is adding a new dependency and want at least one of them to take a look at it.

In D4772#137507, @jon wrote:

https://phab.comm.dev/D4770 should probably be merged before this, not sure how to handle mult-owner stacks though

Add sudo to apt-get commands.

Re-opening diff

Remove quotes around "Install ShellCheck" command.

Use commands we run in Buildkite job instead of unofficial pre-packaged GitHub Action, per @atul's feedback.

CI build error is unrelated to the changes.