@ashoat do you remember why this prop was a string instead of a boolean?

Ah that makes sense! 🤦 Ashoat is the keyserver admin, so the report would only come to him on his account.

For some reason, the Test Plan isn't working for me. Is there something I'm misunderstanding or extra I need to do?

Remove failureMessage prop (see discussion on D4890).

Remove failureMessage prop

I wound't say it is used here. We only set it as a prop of an object, but this prop doesn't seem to be used. Do we really need this prop at all? I'm asking, because if there was a code which used failed message content, this diff should have a place where failed is replaced by failureMessage, but I don't see thing like that.

Herald rule added you

Not too sure about the Nix side of this (looks like @ashoat already gave some high-level feedback which should take precedence over my feedback) but there are some things that can be cleaned up on the Markdown level.

Makes sense, but adding @tomek and @atul as blocking so they can look. feel free to change blocking status.

Just have some questions, but still want @atul and @tomek to take a look.

Yup makes sense!

Only took a quick look because I think at least one of @atul @jacek or @tomek should take a look so not going to request review/accept, but left some inline comments.

Looks good.

Nice, looks like the Buildkite CI passes as well.

This revision is okay, but the rest of the stack still needs to be addressed.

Remove ? from failureMessage's type, making it only string.

Have a hunch that folks on the team are going to ask if we can separate this into separate .sh file or somehow run shellcheck on the contents... might be worth leaving a comment here to preempt that?

Awesome, this guarantees ShellCheck can take a look at the code before reviewers!

Ok, accepting this because the Test Plan worked for me but I'm always wary of accepting diffs that have code that hasn't been explicitly run through the ShellCheck CI. If we could figure that out it'd be awesome!

In D4877#141648, @atul wrote:

I'm also reasoning through InputStateContainer at the moment so understand and appreciate the initiative to try to refactor things!

That said, trying to clean up all of these little stylistic syntax things could be a slippery slope. Even when the changes are simple there's still overhead in terms of putting up a diff, writing out Summary/Test Plan, having it reviewed, etc.

I think we should try to focus our refactoring efforts on changes that help improve comprehension. That could be breaking down chunks of logic into separate functions, renaming variables/functions to be more descriptive, making minor architecture changes to make things more intuitive, etc.

---

The issue you pointed out with failed is a great candidate for improving comprehension via refactoring:

Like failed being a string instead of being a boolean makes little sense. Because if !failed is true (so failed is null basically), that means an upload is in progress, and if failed is not null or undefined (so failed is truthy), that means an upload is NOT in progress. Like what, shouldn't failed being truthy mean an upload failed, since failed being truthy kind of sounds like something failed. just make it a boolean! Then if failed is true, that means the upload failed

---

That said, if you notice these little syntax things as you're working and it's minimal effort to just quickly put up a diff, feel free to keep putting them up! I think it's definitely an improvement, just don't want us to get too carried away with trying to solve all of these minor style things.

Some inline comments and questions. Confirmed the Test Plan worked for me.

Thanks for the inline comments, those are really useful. Maybe one of the diffs in an icons stack could be moved to the Diff Hall of Fame 👀

Confirmed this works.

There are a few icons that don't appear and have a in their place. I'll go through and replace the old icon names with the corresponding new ones.

The filled versions look better in my opinion, so that’s awesome!

It works!

I noticed that you're on master. This PR is to address this exact issue. You can do arc patch D4862 and then try again.

sudo tee /etc/nix/nix.conf > /dev/null

In D4853#140513, @jon wrote:

= is the same as == in any shell that supports [[...]]

Would prefer to use associative arrays, but can't guarantee bash4+ is available until after move to nix dev

In D4844#140414, @jon wrote:

@abosh , please test the nix.conf workflow again.

WARNING: The actual icon changed. I'm using the same cloud icon we decided with Alicja to go with on native. I strongly think we should go with the same filled cloud icon on web because A. consistency B. it looks a lot better than an open path.

Cool! Just some more inline questions I missed on my first pass.

Looks good!

Ok, thanks for addressing my feedback!

trusted users (for cache)

Couldn't different shell settings potentially break reproducibility?

Ok, looks good!

Sorry! My bad, in the rush of trying to get the issue marked as done before the dev sync I forgot to respond. Definitely won’t do that again. I know the importance of “accepting with comments” so I should have been more diligent.

This is so much cleaner, I'm only requesting changes to get your feedback on some inline comments. But this looks so much better!

Additionally, @ashoat and @varun should always be listed as reviewers for docs diffs. But looks like @ashoat already saw/gave feedback on this diff. Adding him just in case.

In D4838#140143, @atul wrote:

Appreciate how quickly you put this up, but unfortunately I'll be recreating this file anyways so we should probably just abandon this diff.

Once recreated, both the filename and font name (which you can find in the information section of Font Book on your Mac, see below) will be in sync