As mentioned in MRL the LLM review part is useful cause it can catch issues, but it also does not clear it in any way of faults, false positives exists. It is quite good at finding copy paste bugs or lookalikes, but it doesn't change other people getting their eyes on and understanding the changes with their existing context

<ofrnxmr:xmr.mx> Right. Im talking about using it to approve prs

Insane, I agree

<ofrnxmr:xmr.mx> Just ranting a bit about the inevitable scenario where people stop using their eyes and start approving because the LLM said so

<slowbeardigger:matrix.org> DataHoarder[m]: Even on how “good” they got lately, the still have hallucinations

Very much so, they are effectively evil genies on acid

<slowbeardigger:matrix.org> In my experience with AI/clankers

<slowbeardigger:matrix.org> If you’re not careful

<slowbeardigger:matrix.org> You may end up doing 4 times more work

Oh yeah, if it's going to do my work it's going to be even slower :D

<slowbeardigger:matrix.org> @ofrnxmr:xmr.mx: Yeah it will happen

<slowbeardigger:matrix.org> DataHoarder[m]: Yup

(that's why myself I send it around doing random throwaway things in the background that just enhance/improve what I do regardless, worst case... most of the time... it does nothing useful and I don't care)

<slowbeardigger:matrix.org> It is weird

<slowbeardigger:matrix.org> They’re good and retarded in a quantum state

<ofrnxmr:xmr.mx> i think therye only good if you can push back on every stupid thing they do

the worst part is that I dig myself on these niche holes and it just keeps pointing to my own resources or tooling to look for help

<jpk68:matrix.org> Forgive me for being out of the loop, but why is there still a bunch of remaining stuff related to paid RPC usage?

<jpk68:matrix.org> Example: github.com/monero-project/monero/bl…er/src/p2p/net_node.inl#L1189-L1190

<jpk68:matrix.org> Will this break compatibility with other node versions if it's removed now?

<ofrnxmr:xmr.mx> we're testing thomas's clankers ability to find the dead code /s

jpk68 opened issue #11003: Default prompt options in the CLI wallet are unintuitive

> monero-project/monero #11003

<ofrnxmr:xmr.mx> its also not aware of when you connect to a restricted node

<ofrnxmr:xmr.mx> the normal way to do the default, would be to list it like [y/N]

<jpk68:matrix.org> Might be a good idea to open a separate issue for that (assuming you're talking to me)

<ofrnxmr:xmr.mx> and still silently accept yes and no

<jpk68:matrix.org> @ofrnxmr:xmr.mx: I agree. [y/N] would be pretty much universally understood, especially for a CLI

<jpk68:matrix.org> A bool could be passed to input_line() for what the default 'highlighted' one should be

<jpk68:matrix.org> This is going to require a huge diff :((

<ofrnxmr:xmr.mx> why? dont need to make it a book, just change the print line

<ofrnxmr:xmr.mx> it already accepts y and defaults to N

<jpk68:matrix.org> I'm stupid, didn't notice that

tobtoht opened pull request #11004: guix: remove distribution package from install docs

> monero-project/monero #11004

.merge+ 10967 10968

Added

jpk68 opened pull request #11005: src: remove dependency on boost spirit

> monero-project/monero #11005

selsta opened pull request #11006: cryptonote_protocol: prevent overlapping block sync spans

> monero-project/monero #11006

selsta opened pull request #11007: cryptonote_protocol: limit the block sync queue dynamically

> monero-project/monero #11007

.merge+ 10918 10917 10884

Added

selsta opened issue #11009: v0.18.5.3 release to-do list

> monero-project/monero #11009

selsta opened pull request #11008: unit_tests: avoid nonexistent TLD in DNSSEC test

> monero-project/monero #11008

<sneedlewoods_xmr:matrix.org> > last release of v0.18

<sneedlewoods_xmr:matrix.org> 👀

.merge+ 10956 10955

Added

.merges

10876 10884

done

.merge+ 11008

Added

monero-project/monero #11010 fixes build

.merge+ 11010

Added

selsta opened pull request #11010: tests: replace removed scope leave helper

> monero-project/monero #11010