[Bug 60241] New: Claude Core review report(a lot of copy paste and logic bugs uncovered)
http://bugs.winehq.org/show_bug.cgi?id=60241 Bug ID: 60241 Summary: Claude Core review report(a lot of copy paste and logic bugs uncovered) Product: Wine Version: 11.15 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@list.winehq.org Reporter: mikrutrafal@protonmail.com Target Milestone: --- Distribution: --- Created attachment 81942 --> http://bugs.winehq.org/attachment.cgi?id=81942 Html report, with ~1900 possible bugs in various modules Over the past month, whenever I had some free tokens available, I used Claude Code to review the Wine(and also other open source projects) codebase step by step I have attached an HTML file containing the graphical report, which contains info about ~1900 problematic places(copy-paste bugs, use-after-free, logic problems, etc.). I know that reporting multiple problems in a single bug report is usually not encouraged, but otherwise I would have flooded the entire Bugzilla tracker. Html report can also be found here: https://github.com/qarmin/ClaudeReports/blob/master/wine_20260823.html I have created reports using the same html template for many other open-source projects, like Box64, FEX, image-rs, lofty, Strawberry, and many others. These projects have already fixed bugs that were found through these reports(there were also some false positives). The report contains direct links to the Wine GitLab repository, the exact commit on which the report was created, a description of each bug, and a possible fix. I can regenerate the report if needed. Here are some examples of bugs that I'm sure are actual bugs: //////////////////////////////////////////////////// ### CPY_3 `HIGH` **Description:** In `ImmGetImeMenuItemsA` and `ImmGetImeMenuItemsW`, the per-item conversion loop copies from a fixed index `1` instead of the loop variable `i`: `memcpy( &menuA[i], &menuW[1], sizeof(IMEMENUITEMINFOA) )` and, symmetrically, `memcpy( &menuW[i], &menuA[1], sizeof(IMEMENUITEMINFOA) )`. Every output element ends up filled with data copied from source index `1` (wrong data for all `i != 1`), and when `ret` is `1` this also reads `menuW[1]`/`menuA[1]`, one element past what was populated/allocated for a single-item result - an out-of-bounds read. **Locations:** ```c memcpy( &menuA[i], &menuW[1], sizeof(IMEMENUITEMINFOA) ); ``` **Fix:** Use the loop index instead of the literal `1` in both functions: ```c memcpy( &menuA[i], &menuW[i], sizeof(IMEMENUITEMINFOA) ); ``` //////////////////////////////////////////////////// ### LOGIC_66 `MEDIUM` **Description:** In `EMFDC_PlgBlt()`, the bounding-box computation loop updates `x_min`, `y_min`, `x_max` correctly with `min()`/`max()` against their own running value, but `y_max` is computed with `max( y_min, points[i].y )` instead of `max( y_max, points[i].y )`. This is a copy-paste typo that makes the computed `emr->rclBounds.bottom` wrong whenever `y_max` and `y_min` diverge. **Locations:** dlls/gdi32/emfdc.c:1875 ``` x_min = min( x_min, points[i].x ); y_min = min( y_min, points[i].y ); x_max = max( x_max, points[i].x ); y_max = max( y_min, points[i].y ); ``` **Fix:** ```c // before y_max = max( y_min, points[i].y ); // after y_max = max( y_max, points[i].y ); ``` //////////////////////////////////////////////////// ### CPY_52 `MEDIUM` **Description:** In `ace_flags_to_samba()` the branch for `CONTAINER_INHERIT_ACE` sets `SEC_ACE_FLAG_NO_PROPAGATE_INHERIT` instead of `SEC_ACE_FLAG_CONTAINER_INHERIT`. This is a copy-paste from the next line (`NO_PROPAGATE_INHERIT_ACE`), so `CONTAINER_INHERIT_ACE` is silently dropped and duplicated as `NO_PROPAGATE_INHERIT_ACE` whenever a share's DACL/SACL ACE flags are converted for Samba, corrupting ACL inheritance semantics passed to `NetShareAdd`/`NetShareGetInfo`. **Locations:** dlls/netapi32/unixlib.c:427 ``` if (flags & OBJECT_INHERIT_ACE) ret |= SEC_ACE_FLAG_OBJECT_INHERIT; if (flags & CONTAINER_INHERIT_ACE) ret |= SEC_ACE_FLAG_NO_PROPAGATE_INHERIT; if (flags & NO_PROPAGATE_INHERIT_ACE) ret |= SEC_ACE_FLAG_NO_PROPAGATE_INHERIT; ``` **Fix:** Change the `CONTAINER_INHERIT_ACE` mapping to use the correct destination flag: ```c if (flags & OBJECT_INHERIT_ACE) ret |= SEC_ACE_FLAG_OBJECT_INHERIT; if (flags & CONTAINER_INHERIT_ACE) ret |= SEC_ACE_FLAG_CONTAINER_INHERIT; if (flags & NO_PROPAGATE_INHERIT_ACE) ret |= SEC_ACE_FLAG_NO_PROPAGATE_INHERIT; ``` -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60241 Ken Sharp <imwellcushtymelike@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Ken Sharp <imwellcushtymelike@gmail.com> --- 1 Find ONE bug. 2. Report it. 3. GOTO 1 Don't use AI. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60241 Nikolay Sivov <bunglehead@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|INVALID |--- Status|RESOLVED |UNCONFIRMED --- Comment #2 from Nikolay Sivov <bunglehead@gmail.com> --- (In reply to Ken Sharp from comment #1)
1 Find ONE bug. 2. Report it. 3. GOTO 1
Don't use AI.
That doesn't seems like a reasonable approach. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60241 Stian Low <wineryyyyy@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wineryyyyy@gmail.com --- Comment #3 from Stian Low <wineryyyyy@gmail.com> --- (In reply to Nikolay Sivov from comment #2)
That doesn't seems like a reasonable approach.
Indeed it seems unreasonable to auto create a bug per item and reporter was wise to guide the tool to avoid flooding Bugzilla. The LLM may have just used existing code analysis tools like SonarQube that predate latest LLM hype to compile the results. Adding a code smeller as part of Gitlab CI/CD workflow may produce a similar report and help devs catch bugs prior rather than after commits/merges which may avoid adding more to the list. Such tools also commonly offer ways to flag false positives so that they may be treated as lesser priority and reduce overall noise. Having these types of code smeller tools as part of Gitlab workflow seems to make more sense than running them as a separate independent efforts. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60241 Olivier F. R. Dierick <o.dierick@piezo-forte.be> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |o.dierick@piezo-forte.be --- Comment #4 from Olivier F. R. Dierick <o.dierick@piezo-forte.be> --- Hello, (In reply to Ken Sharp from comment #1)
1 Find ONE bug. 2. Report it. 3. GOTO 1
I agree with Ken Sharp. "When to report a bug You should report a bug when: •Wine doesn't run a program the same way as Windows does (e.g. crashes) with the default Wine configuration (i.e. no dlls from Windows, or DllOverrides set). (...)" "How to report Each bug report should cover one problem. If there are additional problems with the same application or game, file separate reports for each.(...)" Our bug writing policies are entirely based on "an application is not working" and "one issue per report" approach. This is a realistic approach that allows issue tracking and developers to work on well defined tasks. It's the responsibility of the bug reporter to check if the issue exist (and if it's still present in new wine release). (In reply to Nikolay Sivov from comment #2)
That doesn't seems like a reasonable approach.
What would be a reasonable approach, then? It's not reasonable to report 1900 "possible" bugs in a single bug (or auto-generated individual reports), and expect the Wine developers to assert the existence of those "potential" issues, to sort what's valuable or not. It amounts to a "fix all what this AI says are bugs in Wine" metabug. To me, it's invalid. If not invalid, then who's going to read that report? to get what out of it? and how are we supposed to track such bug? (In reply to Rafał Mikrut from comment #0)
////////////////////////////////////////////////////
### CPY_3 `HIGH`
**Description:** In `ImmGetImeMenuItemsA` and `ImmGetImeMenuItemsW`, the per-item conversion loop copies from a fixed index `1` instead of the loop variable `i`: `memcpy( &menuA[i], &menuW[1], sizeof(IMEMENUITEMINFOA) )` and, symmetrically, `memcpy( &menuW[i], &menuA[1], sizeof(IMEMENUITEMINFOA) )`. Every output element ends up filled with data copied from source index `1` (wrong data for all `i != 1`), and when `ret` is `1` this also reads `menuW[1]`/`menuA[1]`, one element past what was populated/allocated for a single-item result - an out-of-bounds read.
**Locations:** ```c memcpy( &menuA[i], &menuW[1], sizeof(IMEMENUITEMINFOA) ); ``` **Fix:** Use the loop index instead of the literal `1` in both functions: ```c memcpy( &menuA[i], &menuW[i], sizeof(IMEMENUITEMINFOA) ); ```
The original code is valid, if the intent is to initialize the item with index i in menuA[] with the content of the item with fixed index 1 of menuW[]. The analysis doesn't provide any context to check what that function is actually doing, so that "potential" issue requires validation by checking the original intent and if the code is a correct implementation of it.
////////////////////////////////////////////////////
### LOGIC_66 `MEDIUM`
**Description:** In `EMFDC_PlgBlt()`, the bounding-box computation loop updates `x_min`, `y_min`, `x_max` correctly with `min()`/`max()` against their own running value, but `y_max` is computed with `max( y_min, points[i].y )` instead of `max( y_max, points[i].y )`. This is a copy-paste typo that makes the computed `emr->rclBounds.bottom` wrong whenever `y_max` and `y_min` diverge.
**Locations:** dlls/gdi32/emfdc.c:1875 ``` x_min = min( x_min, points[i].x ); y_min = min( y_min, points[i].y ); x_max = max( x_max, points[i].x ); y_max = max( y_min, points[i].y ); ```
**Fix:**
```c // before y_max = max( y_min, points[i].y );
// after y_max = max( y_max, points[i].y ); ```
What if the copy-paste error is in the "x_max = max( x_max, ..." that should have been "x_max = max( x_min, ...". Maybe the code initialize x_min and y_min to some value to be compared with points[i] to get min and max of each. Again, there is no context to validate what the code has to achieve and the potential issue requires manual investigation.
//////////////////////////////////////////////////// ### CPY_52 `MEDIUM`
**Description:** In `ace_flags_to_samba()` the branch for `CONTAINER_INHERIT_ACE` sets `SEC_ACE_FLAG_NO_PROPAGATE_INHERIT` instead of `SEC_ACE_FLAG_CONTAINER_INHERIT`. This is a copy-paste from the next line (`NO_PROPAGATE_INHERIT_ACE`), so `CONTAINER_INHERIT_ACE` is silently dropped and duplicated as `NO_PROPAGATE_INHERIT_ACE` whenever a share's DACL/SACL ACE flags are converted for Samba, corrupting ACL inheritance semantics passed to `NetShareAdd`/`NetShareGetInfo`.
**Locations:** dlls/netapi32/unixlib.c:427 ``` if (flags & OBJECT_INHERIT_ACE) ret |= SEC_ACE_FLAG_OBJECT_INHERIT; if (flags & CONTAINER_INHERIT_ACE) ret |= SEC_ACE_FLAG_NO_PROPAGATE_INHERIT; if (flags & NO_PROPAGATE_INHERIT_ACE) ret |= SEC_ACE_FLAG_NO_PROPAGATE_INHERIT; ```
**Fix:** Change the `CONTAINER_INHERIT_ACE` mapping to use the correct destination flag: ```c if (flags & OBJECT_INHERIT_ACE) ret |= SEC_ACE_FLAG_OBJECT_INHERIT; if (flags & CONTAINER_INHERIT_ACE) ret |= SEC_ACE_FLAG_CONTAINER_INHERIT; if (flags & NO_PROPAGATE_INHERIT_ACE) ret |= SEC_ACE_FLAG_NO_PROPAGATE_INHERIT; ```
What if the code just deal with setting SEC_ACE_FLAG_NO_PROPAGATE_INHERIT, and must do so whether CONTAINER__INHERIT_ACE or NO_PROPAGATE_INHERIT_ACE is set? Again, without context, there is no proof that the code is actually wrong, and like the other issues, this need manual investigation to even know if there is an actual problem with that. Note that the AI statements "this is a copy-paste from the ... line" is unfounded. How could the AI know which line was copied from which other, or even that they are actually copied and not just similar? This is just one more case of AI confident & eloquent presentation and positive assertion of factually false information. Regards. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60241 Olivier F. R. Dierick <o.dierick@piezo-forte.be> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #5 from Olivier F. R. Dierick <o.dierick@piezo-forte.be> --- (In reply to Rafał Mikrut from comment #0)
I know that reporting multiple problems in a single bug report is usually not encouraged, but otherwise I would have flooded the entire Bugzilla tracker.
False excuse. You would have flooded the entire Bugzilla tracker only if you did file a report for every single bug, a thing that you could easily avoid by simply not doing. You had a choice and you choose to be lazy. This is just a no-effort whatsoever bug report and it deserves being rejected. Regards. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60241 --- Comment #6 from Stian Low <wineryyyyy@gmail.com> --- (In reply to Olivier F. R. Dierick from comment #5)
This is just a no-effort whatsoever bug report and it deserves being rejected.
As a bug report, rejection as invalid may be appropriate. But as a feature request to add LLM-free code analysis/smeller tools as part of Gitlab CD/CI workflow, it may worthy of further discussion. However such feature requests may be more appropriately/likely raised by internal Wine devs. Perhaps such Gitlab tools/plugins have already been considered and discussed and rejected to reduce noise of false positives and simplify code review and merge requests. If not then recommending these tools may be treated differently as a feature request vs bug report. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60241 Austin English <austinenglish@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #7 from Austin English <austinenglish@gmail.com> --- Closing. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60241 Nikolay Sivov <bunglehead@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |REOPENED Resolution|INVALID |--- Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #8 from Nikolay Sivov <bunglehead@gmail.com> --- (In reply to Olivier F. R. Dierick from comment #5)
(In reply to Rafał Mikrut from comment #0)
I know that reporting multiple problems in a single bug report is usually not encouraged, but otherwise I would have flooded the entire Bugzilla tracker.
False excuse. You would have flooded the entire Bugzilla tracker only if you did file a report for every single bug, a thing that you could easily avoid by simply not doing. You had a choice and you choose to be lazy.
This is just a no-effort whatsoever bug report and it deserves being rejected.
Regards.
Just leave it as is. There is no need for that kind of policing, as long as there are valid issues in the port there is no harm in it sitting there open. I'll mark it as an enhancement if it's too disturbing. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60241 --- Comment #9 from Alexandre Julliard <julliard@winehq.org> --- Agreed, filing one bug per issue is not reasonable in this case. We don't do it for Coverity issues either. That log is still useful to have, people who are interested can pick up individual issues from there. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60241 --- Comment #10 from Ken Sharp <imwellcushtymelike@gmail.com> --- I've never seen a Coverity metabug with 1900 "possible" bugs. This will sit here for twenty years and never be fixed. Apparently we don't have metabugs though. Anyone interested in AI reports can run AI reports, they don't need to spam Bugzilla unless an actual bug has been found. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60241 --- Comment #11 from Ken Sharp <imwellcushtymelike@gmail.com> --- Other vague bug reports I can open: Report: Tests fail on Windows 10 eventlog.c:84: Test failed: BackupEventLogA failed, le=5 eventlog.c:89: Test failed: Expected a backup file attribs=0xffffffff le=2 eventlog.c:247: Test failed: Expected a handle, le=2 eventlog.c:254: Test failed: Expected success : 6 eventlog.c:255: Test failed: Expected the number of records eventlog.c:84: Test failed: BackupEventLogA failed, le=5 eventlog.c:89: Test failed: Expected a backup file attribs=0xffffffff le=2 eventlog.c:307: Test failed: Expected a handle eventlog.c:314: Test failed: Expected success : 6 eventlog.c:315: Test failed: Expected the number of the oldest record eventlog.c:360: Test failed: Expected success : 5 eventlog.c:362: Test failed: Expected a backup file eventlog.c:370: Test failed: Expected ERROR_ALREADY_EXISTS, got 5 eventlog.c:378: Test failed: Expected a handle eventlog.c:383: Test failed: Expected success : 6 eventlog.c:384: Test failed: Expected a backup file eventlog.c:84: Test failed: BackupEventLogA failed, le=5 eventlog.c:89: Test failed: Expected a backup file attribs=0xffffffff le=2 eventlog.c:584: Tests skipped: We don't have a backup eventlog to work with eventlog.c:84: Test failed: BackupEventLogA failed, le=5 eventlog.c:89: Test failed: Expected a backup file attribs=0xffffffff le=2 eventlog.c:664: Test failed: Expected a handle eventlog.c:691: Test failed: Could not delete the backup file eventlog.c:715: Tests skipped: Could not create the eventlog 'Wine' registry key eventlog.c:1306: Tests skipped: need admin rights eventlog.c:1538: Test failed: Expected 36679, got 36678 eventlog.c:1573: Test failed: Expected 4, got 7 eventlog.c:1604: Test failed: Expected success : 38 eventlog.c:1605: Test failed: Expected 3, got 0 And that's just one test. Report: UBSan reports multiple issues /home/test/wine-git/tools/winebuild/../tools.h:868:5: runtime error: null pointer passed as argument 2, which is declared to never be null /home/test/wine-git/tools/widl/header.c:391:5: runtime error: null pointer passed as argument 1, which is declared to never be null These logs go on forever. Sending fixes where applicable, if anyone is interested. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60241 --- Comment #12 from Alexandre Julliard <julliard@winehq.org> --- (In reply to Ken Sharp from comment #10)
I've never seen a Coverity metabug with 1900 "possible" bugs.
This will sit here for twenty years and never be fixed.
Apparently we don't have metabugs though.
Anyone interested in AI reports can run AI reports, they don't need to spam Bugzilla unless an actual bug has been found.
If someone did the work already, it's useful to have the report. Sure, it doesn't fit the standard Bugzilla pattern, and sure, maybe we can build some other infrastructure for these, but in the meantime having it here is fine. Please stop being a jerk to people who are trying to help. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60241 --- Comment #13 from Olivier F. R. Dierick <o.dierick@piezo-forte.be> --- Hello, (In reply to Alexandre Julliard from comment #12)
If someone did the work already, it's useful to have the report. Sure, it
Spending token to get an AI to review the code located at a project URL, and then sending the result to the project team, is not "doing the work". Did the OP read and analyze that code review, validate and triage each issue (or even a single one)? No. All the work has yet to be done.
doesn't fit the standard Bugzilla pattern, and sure, maybe we can build some other infrastructure for these, but in the meantime having it here is fine.
Why should we break the long standing bug writing policies that bug triagers are required to enforce? Just because you see value in that AI code review? What about the mailing lists? Are they useless to you, or what? This bug report is just a link to a html file. Couldn't this AI review be just sent on the developers mailing list?
Please stop being a jerk to people who are trying to help. What about you start first and stop calling jerks the people that are trying to help you by triaging bugs and enforcing your own policies?
Regards. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60241 --- Comment #14 from Alexandre Julliard <julliard@winehq.org> --- (In reply to Olivier F. R. Dierick from comment #13)
Spending token to get an AI to review the code located at a project URL, and then sending the result to the project team, is not "doing the work". Did the OP read and analyze that code review, validate and triage each issue (or even a single one)? No. All the work has yet to be done.
Actually they did point out 3 issues that are very much real bugs. There are many more real bugs in that report. Even if you are not a fan of AI, you have to admit that it is useful data.
Please stop being a jerk to people who are trying to help. What about you start first and stop calling jerks the people that are trying to help you by triaging bugs and enforcing your own policies?
If you are participating in bug triaging, you are the public face of the project, and you have a responsibility to be nice and welcoming to users, even if they don't conform to your strict idea of the rules. If you can't do that, you'll be asked to stop participating. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60241 --- Comment #15 from Stian Low <wineryyyyy@gmail.com> ---
Actually they did point out 3 issues that are very much real bugs. There are many more real bugs in that report. Even if you are not a fan of AI, you have to admit that it is useful data.
Knowing how the report was produced may also be useful for WineHQ. For example, if it just used Coverty with different settings then that's something WineHQ could reproduce but more integral with existing CD/CI workflows. However if it behaves more like a black box unable to clarify to someone how to reproduce the report and is considered a competitor vs user of Coverty then it approaches conflict with WineHQ's current LLM policy.
If you are participating in bug triaging, you are the public face of the project, and you have a responsibility to be nice and welcoming to users, even if they don't conform to your strict idea of the rules. If you can't do that, you'll be asked to stop participating.
Generally anyone reporting any bug should be met with appreciation. Excessive slop may warrant criticism but when human touch is sensed such as the case of this report then it should be handled in a less rude manner. Other LLM reports with less human touch may need some extra aggressiveness to help them learn better. Bug reporters stating upfront that they used AI should also be appreciated because it helps devs with context which may warrant more skepticism. Also, LLMs that only report bugs and not patches should also be appreciated because they are learning to conform with WineHQ's LLM policy which considers patch risky since internal Microsoft code could have been used as part of training thus violating mission critical clean rule policies. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60241 --- Comment #16 from Stian Low <wineryyyyy@gmail.com> --- (In reply to Olivier F. R. Dierick from comment #13)
Spending token to get an AI to review the code located at a project URL, and then sending the result to the project team, is not "doing the work". Did the OP read and analyze that code review, validate and triage each issue (or even a single one)? No. All the work has yet to be done.
Energy was spent so some work was done. Determining actual useful work vs wasted energy will be needed to further expose over-inflated AI bubbles. Assuming and treating AI/LLM reports as wasteful may be valid but whoever does so should be willing to do their duty of exposing the waste. Negative attitudes toward anyone not undermining AI bubbles and motives behind them are understandable so being a jerk at best may feel like a form of tough love. However AI is forced upon folks now more than ever ironically limiting choices and opportunities so empathizing with their situation may help. It's a pity intelligence seems ever degraded by and conflated with the artificial that disregards cost benefit analysis that wisers may have considered not worth the waste but it will take another paradigm shift to escape latest state of slop-overflow. Inability to cite/credit sources and tendency to plagiarize seems the major flaw (by design) meant to sell intelligence vs other less hyped tools and seems the root of the problem of deciding how to treat the HTML report. If AI/LLMs were more transparent then they may be treated as more trustworthy especially regarding risks around WineHQ's current LLM policy. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60241 --- Comment #17 from Olivier F. R. Dierick <o.dierick@piezo-forte.be> --- Hello, I have an atypical personality. I'm not like you, any of you. Regards. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60241 Olivier F. R. Dierick <o.dierick@piezo-forte.be> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |gitlab-unknown Product|Wine |WineHQ Gitlab Version|11.15 |unspecified -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60241 --- Comment #18 from Olivier F. R. Dierick <o.dierick@piezo-forte.be> --- Hello. If this is an enhancement request, it relates to the development workflow on Gitlab. Changing the product to reflect that. Regards. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60241 --- Comment #19 from Rafał Mużyło <galtgendo@o2.pl> --- (In reply to Olivier F. R. Dierick from comment #18)
If this is an enhancement request, it relates to the development workflow on Gitlab. Changing the product to reflect that.
Someone is trying to be passive-aggressive here and in a pretty silly way too. First part is a whatever, second on the other hand... This bug is a *wine* bug. The fact that a discussion about wine bug wrangling policies has arisen while discussing bug's merits is irrelevant. Perhaps making a copy of this bug to discuss those would be reasonable, but changing bug component to an unrelated topic borders on vandalism. Of course, I'm not a part of the team, so that's just my personal, twisted opinion on the current state of things. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60241 --- Comment #20 from Stian Low <wineryyyyy@gmail.com> --- (In reply to Rafał Mużyło from comment #19)
This bug is a *wine* bug. The fact that a discussion about wine bug wrangling policies has arisen while discussing bug's merits is irrelevant. Perhaps making a copy of this bug to discuss those would be reasonable, but changing bug component to an unrelated topic borders on vandalism.
Whatever allows this to remain open and appear in folks search results when seeking worthy bugs to work is most relevant. Any other lesser relevant topics raised were in service of that most relevant goal. I was unaware any such code analysis tools like Coverty were commonplace part of workflows so the discussion has been informative. Maybe Coverty is used in a less official way because it seems to be missing from mention by the wiki. Resistance to this bug seems primarily caused by being a bug about bugs vs just one of them but auto creating one bug per report seems impractical vs addressing each more manually and vetting on case-by-case basis. If a tool like Coverty were made more official and part of Gitlab workflow then the report of bugs/findings may be available officially from Gitlab. Then it may be reasonable for someone to create a bug to resolve all Gitlab/Coverty or alt-tools findings. It may also be reasonable for folks to create separate bug reports per items as individually addressed and link them to that wider report/effort to resolve all findings.
Of course, I'm not a part of the team, so that's just my personal, twisted opinion on the current state of things.
Nor do I have trust/privileges to change Bugzilla despite always being driven in service of whatever optimizes folks Bugzilla search results. Luckily Bugzilla supports much of that effort without needing elevated privileges. Thanks to reporter for the help raising awareness and igniting a relevant conversation about how to manage such a report going forward. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60241 Alexandre Julliard <julliard@winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|gitlab-unknown |-unknown Severity|enhancement |normal Product|WineHQ Gitlab |Wine --- Comment #21 from Alexandre Julliard <julliard@winehq.org> --- Olivier, please stop messing with this bug, it's fine as it is. Please just move on. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60241 --- Comment #22 from Stian Low <wineryyyyy@gmail.com> --- (In reply to Olivier F. R. Dierick from comment #17)
I have an atypical personality. I'm not like you, any of you.
Decades of career across industries has proved such atypical is quite typical especially among tech/dev workers. Your alternative perspectives/opinions are appreciated. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60241 --- Comment #23 from Olivier F. R. Dierick <o.dierick@piezo-forte.be> --- (In reply to Alexandre Julliard from comment #21)
Olivier, please stop messing with this bug, it's fine as it is. Please just move on.
Hello, Your fascination for AI is altering your judgment and it confuses you. For as long as I've been contributing here, I have been always told that Bugzilla was not a place for user help or philosophical debate (although some senior developers tends to ignore that when they see fit), that there were policies and that bug triagers were tasked to enforce them and make sure that the bug conformed to them so that it was easier for developers to pick issues to work on. Now you're going against that, you suddenly have expectations disjointed from reality (Bugzilla is not your free customer support, we are volunteers that do not work for you and don't have to follow a "nice and welcoming to the users" code of conduct when triaging bugs, if you want that put an AI chatbox on the main page to redirect users to the appropriate places, I'm sure AI will always be nice and welcoming) and you're going to fight with the people that are contributing to the project. Why? because you're hurt by the rejection of a bug related to an AI report? I'm not responsible for the bug being changed to an enhancement request, but my understanding of the discussion is that the enhancement request is about integrating AI tool/code smeller in the development workflow. The enhancement request is not about adding AI tool/code smeller into the WINE code (I refer to the comments from Stian Low for that). So it seems logical to me to maintain coherence in the bug database that the product field is changed to gitlab. Now explain to me how triaging the bug according to the other people concensus is wrong. Isn't it just because you took a gripe against me? Note that I initially considered replying to Stian Low that bugzilla was not a place for discussion and that it should be directed at the developers mailing list, but after your interventions I guess that would have made me "too strict" and not "nice and welcoming", so I'll let you be the one that tells me to stop. And last, I will ask you to clarify several points, so that the triaging of this bug has clear and well defined instructions: If someone interested picks up an issue from the AI report, how are we going do deal with that? Should we direct the person to file a separate bug report or to comment on this bug? Because we'll need a way to track when one of the 1900 issues is worked on/fixed, don't you think? How will we have to deal with other code reviews from the same/different AI. Should we mark the reports duplicate of this one, or will they be tracked independently? Because if we accept one AI report, we'll soon get others, don't you think? How are we going to disambiguate the duplicate issues in various code reviews? Should we not list the 1900 issues to identify them? How are we going to deal with the bug when several wine releases have passed and the AI code review is no longer current? Someone have to ask Claude for a renewed code review, don't you think? Then how are we going to reproduce the code review? We'll need to know how the code review was produced. Does it use a prompt, or an interface with parameters? Then which prompt or parameters were used to produce this code review? We should ask the OP the step to reproduce the report, don't you think? Regards. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60241 --- Comment #24 from Olivier F. R. Dierick <o.dierick@piezo-forte.be> --- (In reply to Rafał Mużyło from comment #19)
Someone is trying to be passive-aggressive here and in a pretty silly way too.
I suppose that is your motive for intervening here. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60241 --- Comment #25 from Olivier F. R. Dierick <o.dierick@piezo-forte.be> --- (In reply to Stian Low from comment #22)
(In reply to Olivier F. R. Dierick from comment #17)
I have an atypical personality. I'm not like you, any of you.
Decades of career across industries has proved such atypical is quite typical especially among tech/dev workers.
Your alternative perspectives/opinions are appreciated.
Hello, Thanks. Your contributions are appreciated, too. Regards. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60241 --- Comment #26 from Hans Leidekker <hans@meelstraat.net> --- (In reply to Olivier F. R. Dierick from comment #23)
If someone interested picks up an issue from the AI report, how are we going do deal with that? Should we direct the person to file a separate bug report or to comment on this bug? Because we'll need a way to track when one of the 1900 issues is worked on/fixed, don't you think?
That's not practical because of the large number. Many bugs get fixed without a bug report, that's not a problem. We can ask the reporter to repeat the review after some time to see what issues are left. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60241 --- Comment #27 from Stian Low <wineryyyyy@gmail.com> --- (In reply to Stian Low from comment #6)
But as a feature request to add LLM-free code analysis/smeller tools as part of Gitlab CD/CI workflow, it may worthy of further discussion.
(In reply to Olivier F. R. Dierick from comment #23)
I'm not responsible for the bug being changed to an enhancement request, but my understanding of the discussion is that the enhancement request is about integrating AI tool/code smeller in the development workflow.
One very important clarification. I specifically suggested *LLM-free smellers/analysis tools that predate modern AI by decades which are unlikely to conflict with current WineHQ LLM policy. I was and and will no advocate for LLMs against WineHQ current LLM policy which I respect and fully support as part of what makes Wine project outstanding despite perhaps being merely a consequence of having to avoid copyright risks vs any philosophical integrity. I'm very critical of AI and consider it funded by the worst willing sacrifice the world to steal all power and escape what they fear most and if they can't they're willing to bring everyone with them. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60241 --- Comment #28 from Stian Low <wineryyyyy@gmail.com> --- (In reply to Stian Low from comment #27)
I was and and will no advocate for LLMs against WineHQ current LLM policy
Apologies for some of my Bugzilla messages getting butchered. Sometimes my edits seem to be lost when resubmitted by errors maybe caused by VPN. Maybe its my negligence to proof read also. Having worked within the AI hype field earlier I'm relieved of having insider insight into the diminishing returns and deliberately choose not to contribute to the hype regardless of my own detriment. Whatever detriment incurred is nothing compared to the fools who will never make up for sunken costs for what they were promised. Even Einsteins nuclear brilliance isn't enough to power the same level of intelligence of minuscule calories. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60241 --- Comment #29 from Alexandre Julliard <julliard@winehq.org> --- (In reply to Olivier F. R. Dierick from comment #23)
(In reply to Alexandre Julliard from comment #21)
Olivier, please stop messing with this bug, it's fine as it is. Please just move on.
Hello,
Your fascination for AI is altering your judgment and it confuses you.
I have no love for AI, but I'm still able to recognize that this report is useful.
For as long as I've been contributing here, I have been always told that Bugzilla was not a place for user help or philosophical debate (although some senior developers tends to ignore that when they see fit), that there were policies and that bug triagers were tasked to enforce them and make sure that the bug conformed to them so that it was easier for developers to pick issues to work on.
Exactly, the goal is to make the work easier for developers. Here, developers have told you that this bug is useful, and that it is the right way to handle that sort of report. You should listen to them, instead of insisting on blindly applying rules that will make it harder to fix the bugs.
Now you're going against that, you suddenly have expectations disjointed from reality (Bugzilla is not your free customer support, we are volunteers that do not work for you and don't have to follow a "nice and welcoming to the users" code of conduct when triaging bugs, if you want that put an AI chatbox on the main page to redirect users to the appropriate places, I'm sure AI will always be nice and welcoming) and you're going to fight with the people that are contributing to the project. Why? because you're hurt by the rejection of a bug related to an AI report?
No, because I think this report is useful and will enable us to fix bugs, which is supposed to be the goal of a bug tracker. And BTW if you want to participate in the project, you absolutely have to follow our code of conduct, volunteer or not. If you can't do that you will be banned.
I'm not responsible for the bug being changed to an enhancement request, but my understanding of the discussion is that the enhancement request is about integrating AI tool/code smeller in the development workflow. The enhancement request is not about adding AI tool/code smeller into the WINE code (I refer to the comments from Stian Low for that). So it seems logical to me to maintain coherence in the bug database that the product field is changed to gitlab. Now explain to me how triaging the bug according to the other people concensus is wrong. Isn't it just because you took a gripe against me?
I don't have any gripe against you. This bug has clearly nothing to do with Gitlab, it's a list of bugs found in the Wine code. The consensus of developers is that this bug is useful. Just accept that and let us work on fixing the issues. If you want to file a bug against Gitlab that there should be some mechanism to generate AI reports, go right ahead. But it's a different bug.
If someone interested picks up an issue from the AI report, how are we going do deal with that? Should we direct the person to file a separate bug report or to comment on this bug? Because we'll need a way to track when one of the 1900 issues is worked on/fixed, don't you think?
No, not really. Most of the issues are trivial and people can just submit fixes without an associated bug. Nikolay fixed quite a few of them already.
How will we have to deal with other code reviews from the same/different AI. Should we mark the reports duplicate of this one, or will they be tracked independently? Because if we accept one AI report, we'll soon get others, don't you think?
If the OP updates the report, it can be attached to this bug. If there are other reports of the same type they can have their own bug. I don't see any problem with that.
How are we going to disambiguate the duplicate issues in various code reviews? Should we not list the 1900 issues to identify them?
No, there's no need to track every single code typo in a separate bug.
How are we going to deal with the bug when several wine releases have passed and the AI code review is no longer current? Someone have to ask Claude for a renewed code review, don't you think?
Then how are we going to reproduce the code review? We'll need to know how the code review was produced. Does it use a prompt, or an interface with parameters? Then which prompt or parameters were used to produce this code review? We should ask the OP the step to reproduce the report, don't you think?
We can ask the OP to generate a new report. If someone else is interested in doing this, they can reach out to the OP and ask how to achieve the same results. If no one updates the report and it becomes stale and no longer useful, we can then close the bug. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60241 --- Comment #30 from Olivier F. R. Dierick <o.dierick@piezo-forte.be> --- (In reply to Alexandre Julliard from comment #29) Hello, I'm giving up. Thank you for making me ponder about what's important or not. Regards. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60241 --- Comment #31 from Ken Sharp <imwellcushtymelike@gmail.com> --- (In reply to Olivier F. R. Dierick from comment #30)
(In reply to Alexandre Julliard from comment #29)
Hello,
I'm giving up.
Thank you for making me ponder about what's important or not.
Regards.
Please don't give up. I felt the same way, but just ignore metabugs and carry on. So glad this bug report didn't turn into nonsense spam for everyone... P.S. Anybody can use AI. Most of us don't bother opening bug reports for it. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60241 --- Comment #32 from Olivier F. R. Dierick <o.dierick@piezo-forte.be> --- (In reply to Ken Sharp from comment #31)
Please don't give up. I felt the same way, but just ignore metabugs and carry on.
So glad this bug report didn't turn into nonsense spam for everyone...
P.S. Anybody can use AI. Most of us don't bother opening bug reports for it.
Hello, Thank you for the kind words. Someone might be interested on reading this viewpoint on generative AI: https://meta.stackoverflow.com/questions/421831/policy-generative-ai-e-g-cha... Regards. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60241 Zeb Figura <z.figura12@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com --- Comment #33 from Zeb Figura <z.figura12@gmail.com> --- I really don't like this bug for a lot of reasons, personally. (In reply to Stian Low from comment #15)
However if it behaves more like a black box unable to clarify to someone how to reproduce the report and is considered a competitor vs user of Coverty then it approaches conflict with WineHQ's current LLM policy.
Well, no, because the LLM policy only covers actual code that goes into Wine and it's based only on copyright and licensing law. Personally, I'd prefer to extend the policy to forbid any LLM content anywhere, because it's got horrible ethical problems and categorically wastes time far worse than anything human-generated. The worst human-written bug, containing nothing other than "it doesn't work", is better than an AI bug, because at least you immediately know that all the information is missing, and can eventually tease it out of the reporter, and don't get misled down wrong rabbit holes. Similarly I'd be inclined to not humor this report, even if it is valid, because I don't want to encourage more slop, as it were. (In reply to Olivier F. R. Dierick from comment #23)
For as long as I've been contributing here, I have been always told that Bugzilla was not a place for user help or philosophical debate (although some senior developers tends to ignore that when they see fit), that there were policies and that bug triagers were tasked to enforce them and make sure that the bug conformed to them so that it was easier for developers to pick issues to work on.
As far as I'm concerned, it's a matter of balance. Our policies generally make bugs easier to work with, but too strict adherence to them can make them harder or make the process of triaging and debugging hard. Like, yes, the fact this bug is a metabug that is very hard to tell when it's properly closed is bad, but 1900 individual bugs would be worse. Similarly a lot of off-topic discussion, or user aid, can clog up a bug, but that doesn't mean that a little bit, like a sentence telling the user what winetricks workaround they can use, is unacceptable; indeed it's significantly less work than the alternative. Similarly, to address a complaint by Stian in some bug I forget, you don't have to be entirely soulless or robotic, but getting into a long tangent isn't great, and bringing up politics is a bad idea. I think the treatment of individual bugs, as well as policies, should be informed by what's useful to both developers and non-developer triagers, and that exceptions should be made if the policy isn't going to be helpful in a given scenario. Not every bug is alike; this is one of the weird ones. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60241 Olivier F. R. Dierick <o.dierick@piezo-forte.be> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|o.dierick@piezo-forte.be | -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60241 --- Comment #34 from Stian Low <wineryyyyy@gmail.com> --- (In reply to Zeb Figura from comment #33)
Well, no, because the LLM policy only covers actual code that goes into Wine and it's based only on copyright and licensing law.
Right. Report includes suggested fixes to bugs/findings but unclear how they may have been derived: - Fixes from legacy tools predating LLM that may not violate copyright - Fixes from LLM being trained on wine code which may not violate copyright - Fixes from LLM being trained on Microsoft/copyright code which is less clear and risky I believe these inherent risks from lack of transparency are the point by design by AI companies. They operate much like Microsoft which was a significant driver of the free software movement. I consider AI/LLMs by these companies not meant to elevate free software but rather to sabotage it. I do not trust them any more than I've ever trusted Microsoft.
Personally, I'd prefer to extend the policy to forbid any LLM content anywhere,
We are aligned there.
horrible ethical problems and categorically wastes time far worse than anything human-generated
Add waste of scarce energy/resources as LLMs are ironically sold as tools for abundance. Add Enron-like blatant lies and deception as unethical business practices among all the others. Slop era is built on a gambled house of cards. Gamblers were promised a house of royal flushes but got a house of folds that will collapse. I consider limiting dependence on these companies and tools wise to continue business as usual vs those who will collapse with it. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60241 --- Comment #35 from Rafał Mikrut <mikrutrafal@protonmail.com> --- Created attachment 82094 --> http://bugs.winehq.org/attachment.cgi?id=82094 Updated report 12.09.2026 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60241 --- Comment #36 from Rafał Mikrut <mikrutrafal@protonmail.com> ---
Spending token to get an AI to review the code located at a project URL and then sending the result to the project team, is not ‘doing the work’.
I don't really agree that the amount of manual effort changes whether the report is useful. What matters to me is whether it helps developers find and fix actual problems and in this case I think it clearly does, because as of now, roughly 10-15% of the findings in the report have already resulted in code being fixed by Nikolay, Hans and a few other contributors, who have spent considerable effort looking into these issues.
Anyone interested in AI reports can run AI reports, they don't need to spam Bugzilla unless an actual bug has been found.
When I was more active in Godot, I spent a lot of time finding bugs through testing and static analysis and I regularly used Coverity, Cppcheck and other tools, which I also tried to encourage people to use. In practice, however, very few people used them, partly because the results lived behind a separate service, required additional effort to set up and partly because they often contained a significant number of false positives. That is also why I started to create these reports in the first place and in this particular format(as a simple HTML page - I started with md files, which were quite ugly and hard to read for some people), with a description, the exact location of the problem and possible fixes, to make the whole issue review process as easy as possible for developers - and for multiple projects this worked really well. Just because anyone can create such a report doesn't really mean much, because how many people have actually done it for Wine? This report, for example, identified an issue that was fixed in https://gitlab.winehq.org/wine/wine/-/merge_requests/11876, which had apparently existed since 2004 (git blame https://gitlab.winehq.org/wine/wine/-/blob/153ea52a1d39a3986348a55aff4a2283e...). As for CI, this was generated using Claude Sonnet and I have already seen a lot of projects experimenting with LLM based analysis in CI just like systemd, but this would be quite a big step to integrate it with GitLab. I think that additional static analyzers added to CI are always a good thing, but except PVS-Studio(which is commercial), I haven't really found any static analyzer with a sufficiently low number of false positives. LLM analyzers, despite generating less reproducible findings, have a pretty big advantage over static analyzers, because they can analyze the context of the code. Overall, a large part of the discussion was mainly about whether AI should be allowed to be used in the project or not and in my opinion it should be, as long as its use provides some benefits. If this issue remains open, I will update these reports from time to time, but if you decide that this kind of issue is not welcome in the repository, I will respect that decision and no longer create such reports. Regarding updates to the report, to avoid spamming this thread, I will only update it here when a significant number of the reported issues have been changed or fixed. In the meantime, I will probably make "silent" updates approximately once a week here - https://github.com/qarmin/ClaudeReports/issues/1, to make it easier for multiple people to coordinate fixing the issues(so nobody has to manually remember which issues have already been fixed). The updated report has already been added as a new attachment - "Updated report 12.09.2026" - https://bugs.winehq.org/attachment.cgi?id=82094 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60241 --- Comment #37 from Alexandre Julliard <julliard@winehq.org> --- (In reply to Rafał Mikrut from comment #36)
Overall, a large part of the discussion was mainly about whether AI should be allowed to be used in the project or not and in my opinion it should be, as long as its use provides some benefits. If this issue remains open, I will update these reports from time to time, but if you decide that this kind of issue is not welcome in the repository, I will respect that decision and no longer create such reports.
Thank you for doing that work, it's definitely useful, and very much appreciated. As you noted, it has resulted in a significant number of bug fixes already.
Regarding updates to the report, to avoid spamming this thread, I will only update it here when a significant number of the reported issues have been changed or fixed. In the meantime, I will probably make "silent" updates approximately once a week here - https://github.com/qarmin/ClaudeReports/issues/1, to make it easier for multiple people to coordinate fixing the issues(so nobody has to manually remember which issues have already been fixed).
That's perfect, thank you! -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla