I use SDCC in my 8051-based keyboard projects. When Claude Fable 5.2 was released, I decided to train myself on what a more autonomous workflow looks like (this is outside of my comfort zone; I normally have AI on a very tight leash). I picked SDCC for a largely automated triage eneavor. While I certainly don't recommend maintainers blindly pluck a bunch of patches from the triage work, I do think there could be some value in helping maintainers identify which open tickets are already resolved, which are not reproducible, and maybe even which are trivial to fix. There are also some unreported bugs that have been identified. Because I'm using Fable+Xhigh for this, it's not a fast effort; it'll take months to get through all of the open bug, feature request, and patch tickets. Still, it interests me enough that I plan to let my spare cycles keep poking at it.
I'm not looking to advertise the fork as something folks should use; it really is just an interesting personal project for me, and if maintainers find anything useful from it, all the better! No qualms if you're inundated with AI information and don't even want to look!
Cheers, and thanks for all the effort you've put into this compiler!
Our capacity for reviewing patches is somewhat limited. So putting all the information from your work into the SDCC ticket trackers is probably too much for now.
Maybe start with the ones in your "trivial fixes" category, since they should be easy to review?
The information from the "already fixed in trunk" category could also be useful - I think we can close many of them after an SDCC dev checks that the issue can't be reproduced in trunk.
I'd suggest to wait the results from the above two first, then look into the other issues again.
That should also give the most benefit quickly - users don't care how much effort it was to review a patch, they just want issues fixed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I use SDCC in my 8051-based keyboard projects. When Claude Fable 5.2 was released, I decided to train myself on what a more autonomous workflow looks like (this is outside of my comfort zone; I normally have AI on a very tight leash). I picked SDCC for a largely automated triage eneavor. While I certainly don't recommend maintainers blindly pluck a bunch of patches from the triage work, I do think there could be some value in helping maintainers identify which open tickets are already resolved, which are not reproducible, and maybe even which are trivial to fix. There are also some unreported bugs that have been identified. Because I'm using Fable+Xhigh for this, it's not a fast effort; it'll take months to get through all of the open bug, feature request, and patch tickets. Still, it interests me enough that I plan to let my spare cycles keep poking at it.
I'm not looking to advertise the fork as something folks should use; it really is just an interesting personal project for me, and if maintainers find anything useful from it, all the better! No qualms if you're inundated with AI information and don't even want to look!
Cheers, and thanks for all the effort you've put into this compiler!
Triage: https://github.com/mdmower/sdcc-triage
Fork: https://github.com/mdmower/sdcc
In the last few months, we have seen a few LLM-ritten bug reports and patches by various users, and a lot of them by @cs99cjb. There also is https://sourceforge.net/p/sdcc/wiki/LLM%20policy/ now.
Our capacity for reviewing patches is somewhat limited. So putting all the information from your work into the SDCC ticket trackers is probably too much for now.
Maybe start with the ones in your "trivial fixes" category, since they should be easy to review?
The information from the "already fixed in trunk" category could also be useful - I think we can close many of them after an SDCC dev checks that the issue can't be reproduced in trunk.
I'd suggest to wait the results from the above two first, then look into the other issues again.
That should also give the most benefit quickly - users don't care how much effort it was to review a patch, they just want issues fixed.