git: 56f47d6b38 - main - Status/2024Q: grammar fixes

From: Maxim Konovalov <maxim_at_FreeBSD.org>
Date: Fri, 03 Jan 2025 17:36:09 UTC
The branch main has been updated by maxim:

URL: https://cgit.FreeBSD.org/doc/commit/?id=56f47d6b38ad7a4643c43e0a255ce9f49f57a603

commit 56f47d6b38ad7a4643c43e0a255ce9f49f57a603
Author:     Maxim Konovalov <maxim@FreeBSD.org>
AuthorDate: 2025-01-03 17:35:16 +0000
Commit:     Maxim Konovalov <maxim@FreeBSD.org>
CommitDate: 2025-01-03 17:35:16 +0000

    Status/2024Q: grammar fixes
---
 website/content/en/status/report-2024-10-2024-12/bugmeister.adoc | 4 ++--
 website/content/en/status/report-2024-10-2024-12/gcc.adoc        | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/content/en/status/report-2024-10-2024-12/bugmeister.adoc b/website/content/en/status/report-2024-10-2024-12/bugmeister.adoc
index d0292571a6..6400b5e129 100644
--- a/website/content/en/status/report-2024-10-2024-12/bugmeister.adoc
+++ b/website/content/en/status/report-2024-10-2024-12/bugmeister.adoc
@@ -49,7 +49,7 @@ Bugmeister folks also did some passes through the database to clean up metadata:
 
  * removed many of the 'patch' keywords from PRs.
    In the optimal case these should now be imputed by metadata in each attachment.
-   In a few cases where patches are submitted inline insteada of as an attachment, the keyword stays.
+   In a few cases where patches are submitted inline instead of as an attachment, the keyword stays.
    There may be a few of these left over from the GNATS conversion.
    The use of inline patches should be discouraged, as automation has no way to detect them.
    Thanks to our triagers, especially Alexander Ziaee.
@@ -58,7 +58,7 @@ There were various discussions about bug futures that came up in various video c
 One is that there is a (supported) successor to Phabricator, which itself is now no longer developed.
 Multiple groups will need to coordinate to evaluate it.
 
-Jan Bramkamp has volunteered to help with the task "automate harvesting PRs and evalauting whether they still apply".
+Jan Bramkamp has volunteered to help with the task "automate harvesting PRs and evaluating whether they still apply".
 Mark Linimon to collaborate.
 
 Clusteradm@ helped us fend off yet another crawler site.
diff --git a/website/content/en/status/report-2024-10-2024-12/gcc.adoc b/website/content/en/status/report-2024-10-2024-12/gcc.adoc
index a278ac71c0..7d7ba34512 100644
--- a/website/content/en/status/report-2024-10-2024-12/gcc.adoc
+++ b/website/content/en/status/report-2024-10-2024-12/gcc.adoc
@@ -14,7 +14,7 @@ As usual, thanks to everyone involved.
 
 If you maintain any of the affected ports or want to give a hand preparing and testing some patches, you can consider trying adding `-fpermissive` to `CFLAGS` in affected ports as a temporary solution: GCC 14 has transformed some warnings into errors, which is the cause of many of the failed builds.
 The `-fpermissive` flag switches those errors back to warnings.
-However, it is preferable that upstream updates its code to remove those warnings completely so that `-fpermissive` is not necessary, possibily with FreeBSD ports maintainers support.
+However, it is preferable that upstream updates its code to remove those warnings completely so that `-fpermissive` is not necessary, possibly with FreeBSD ports maintainers support.
 If the code is not maintained upstream anymore, the time might have come to deprecate the port.
 
 Work has been done on some bugs too, mainly upstream: