On this point specifically:

Your response reads to me as dismissive, and this annoys me. Yes, it does not need to be perfect. However, it needs to be good enough, and the feedback I gave was for various aspects in which I do not believe it is good enough for the project. Once live, the world will have to see and deal with it. I have no clue how long it will take to fix the issues I see that make the site look unprofessional or be painful to navigate. This is compounded by the fact that there has been no recent attempt to solicit feedback and get buy-in from the developer community. This feels like it's being pushed forward whether we like it or not, and that is not a good way to build goodwill. I hope you rethink this strategy and don't continue to burn bridges with the developer community.

Oh and what happened to the sidebar for various pages like https://freebsd.fortasse.cloud/where/? They feel rather lacking without that (pages of text and tables with a lot of empty space around them), and there are various pages on the site I've never known how to find without the sidebar...

Other bug reports (all on Safari):

Just looking at the homepage there is some very strange use of whitespace: specifically, there is a lot of extra vertical whitespace in various places that look unbalanced and make the content too spread out, and there is vertical whitespace lacking in the feed headings. See the attachments for before and after fixing these oddities that make the design feel more cohesive, polished and readable.

Move INSTALLEXTRAKERNELS after NO_INSTALLEXTRAKERNELS is set. Hidden by testing originally on CheriBSD where we set NO_INSTALLEXTRAKERNELS to no early for Morello..

D54291

In D54282#1240665, @ivy wrote:

In D54282#1240471, @jrtc27 wrote:

To avoid breaking existing users of distributekernel (which is what we
currently use to stage the kernel), reimplement stage-packages-kernel
to run make install itself rather than changing the existing behaviour
of distributekernel; this means release builds and other downstream
users are not affected by this change.

Does the confusingly-named NO_INSTALLKERNEL not do what you want?

possibly, but this is an awful hack that works by adding incorrect entries to ${BUILDKERNELS}, which means the logic for create-dtb-package would probably need to be updated to work around that... the amount of new code for this specific change is very small, so i think i prefer doing it this way.

To avoid breaking existing users of distributekernel (which is what we
currently use to stage the kernel), reimplement stage-packages-kernel
to run make install itself rather than changing the existing behaviour
of distributekernel; this means release builds and other downstream
users are not affected by this change.

So the current code tries 10 times to hit a failure, and will use the last value if all 10 reads succeeded, given the condition after the loop is correct? Importantly, there's no security issue here, because we didn't actually report a successful read when it failed?