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 @@ -1,71 +1,71 @@ === Bugmeister Team Links: + link:https://wiki.freebsd.org/Bugzilla[FreeBSD Bugzilla] URL: link:https://wiki.freebsd.org/Bugzilla[] Contact: Bugmeister In this quarter we came even closer to steady-state; we are dealing with incoming PRs more quickly these days. For reference: link:https://bugs.freebsd.org/bugzilla/page.cgi?id=dashboard.html&days=90[] The overall number of PRs came down from slightly over 11,600 to right at 11,000. This was due to work from several people to go over entire groups of PRs (see below). Mark Linimon attended several video calls with various src committers. They are doing some experimentation to learn what kind of effort is sustainable. The most recent effort was to evaluate the latest incoming src PRs; you will note that many of them from the past few weeks have been marked as requesting feedback. Bugmeister folks also did some passes through the database to clean up metadata: * reassigned bugs away from committers who had had their commit bits safekept over the last year. * cleaned up bugs for Product: `Base` System Status: `In Progress`. A number of these were not being actively worked on. The count is down to 184. ** In particular, Mark Linimon believes "assigned to mailing list" means "it is not really In Progress". Perhaps it's been discussed, but we do not really have a state for that. (We can make an argument that that itself is a bug.) ** We are now down to only a handful of the above, from "too many". The concept is to make sure `In Progress` has some real meaning. * evaluated PRs for mfc-stableN. In particular, any having mfc-stable12 had that flag cleared. ** The concept is to make sure these metadata have some real meaning as well: e.g. "a commit has been made and should be evaluated for MFCs". ** There are now a much smaller number of these. * closed numerous PRs as "Overcome By Events": ** (old version) + (contains the string "boot") ** (old version) + (contains the strings "alpha" or "beta") * evaluated "PR shows a commit" (possibly via Phabricator)" and "there was no trailing discussion". ** In a few cases of the above we simply assigned them and made sure that mfc-stable[13|14] was set, if it seemed appropriate. ** This does leave many that have a commit and then have trailing discussion. I think we will need more volunteers to go through those. * 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. There were various discussions about bug futures that came up in various video chats. 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. While that was ongoing, bugzilla was nearly unusable due to timeouts, as were other services hosted on the same machine (wiki and cgit among others). We also welcomed our newest Triage member, Lexi (aka 'ivy' on Discord). Finally, glebius was added to bugmeister@ alias as core.13 liaison. See also: link:https://wiki.freebsd.org/Bugzilla/SearchQueries[] 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 @@ -1,26 +1,26 @@ === GCC on FreeBSD Links: + link:https://gcc.gnu.org/[GCC Project] URL: link:https://gcc.gnu.org/[] + link:https://gcc.gnu.org/gcc-11/[GCC 11 release series] URL: link:https://gcc.gnu.org/gcc-11/[] + link:https://gcc.gnu.org/gcc-12/[GCC 12 release series] URL: link:https://gcc.gnu.org/gcc-12/[] + link:https://gcc.gnu.org/gcc-13/[GCC 13 release series] URL: link:https://gcc.gnu.org/gcc-13/[] + link:https://gcc.gnu.org/gcc-14/[GCC 14 release series] URL: link:https://gcc.gnu.org/gcc-14/[] + Contact: Lorenzo Salvadore The link:https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281091[exp-run to update GCC default version from 13 to 14] is getting forward. 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: - link:https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117210[] has been fixed: a recent change in the FreeBSD headers caused a regression in the GCC 15 development version; - link:https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115008[] has been fixed: this was an issue with posix_fallocate failing on FreeBSD on a ZFS filesystem; - an attempt to fix bug link:https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282797[] specific to aarch64 for -devel ports has failed. If you are able to give a hand on this, it would be very much appreciated. Thanks to everyone who has helped with these issues.