00:22:56 k​ayabanerve:matrix.org: cfg-if is minor sugar which doesn't necessarily work as expected because of how it uses env variables. I'd not recommend using it.
00:24:00 k​ayabanerve:matrix.org: Nested build processes inherit cfg-if declarations even if the nested process shouldn't have them.
06:08:58 c​ryptagupta:matrix.org: yes. i use AI in pretty much all my projects. But I'm responsible for the code at the end of the day.
06:27:20 c​ryptagupta:matrix.org: yes. i work with AI in pretty much all my projects. But I'm responsible for the code at the end of the day.
08:50:27 c​yrix126:gupax.io: Would there be the same issue with https://github.com/rust-lang/rust/issues/115585 ?
09:11:20 k​ayabanerve:matrix.org: Not if it isn't implemented via reading/writing environment variables at time of compile.
13:37:36 s​bt:nope.chat: Not really. It's most of the time slop. Cuprate should ban LLM contributions
13:58:37 b​oog900:monero.social: I think banning it will just lead to people lying
13:59:57 b​oog900:monero.social: In this case it was the PR description that gave it away, it was wayyy too detailed for the given change
14:00:24 b​oog900:monero.social: there was more detail in the description than the actual PR itself.
14:00:59 b​oog900:monero.social: at that point the description just isn't helpful as reading the code is more efficient.
14:03:35 b​oog900:monero.social: If AI was used to make the code changes I also feel Cuprate is probably not the best project to work on.
14:05:53 b​oog900:monero.social: Its ok you to be responsible for the code but that doesn't mean anything when our license explicitly removes all liability for any issues.
14:15:39 b​oog900:monero.social: I think I will accept this PR as its so simple but unless you can work on Cuprate without AI I won't be accepting future PRs.
14:37:31 s​bt:nope.chat: Would be better to have LLM policy like for example incus has https://github.com/lxc/incus/commit/54c3f05ee438b962e8ac459262d509cfb8bcdf30
14:38:26 c​ryptagupta:matrix.org: i disagree. depends how you work with it. it can definitely be slop and with inexperienced devs it sometimes is. but certainly having a policy in place is reasonable.
14:40:39 s​bt:nope.chat: Even if it looks good right now, maintainers have to deal with subtle bugs that go unnoticed in generated code, it's just not worth it
14:42:51 c​ryptagupta:matrix.org: that's certainly your privilege. i would urge you to continue to treat it on a case by case basis (as you did here).
14:42:51 c​ryptagupta:matrix.org: i'm happy to work on the simple stuff that is easy to accept. that allows me to get familiar with the code while still adding something useful to the project. otherwise i would not be able to contribute at all. once i understand the code better i'm happy to contribute with minimal AI assistance.
14:45:03 s​yntheticbird:monero.social: We can discuss in large about the consequences of LLM contributions. For every disagreement you can find an argument for its advocacy. Things like: "the review process should be the same across all PR and not fail based on its origin", or "we can say that if a human take responsibility, the AI slop should not appear". "Instead of banning it, we could also just request honest disclosure."
14:45:05 s​yntheticbird:monero.social: But from an empirical perspective, project that accept LLM assisted contributions naturally tends to lower quality of code than projects that don't.
14:45:07 s​yntheticbird:monero.social: I believe that for a cryptocurrency project where security and quality is critical, pleasing a few contributors, may there intentions be good in the first place, is not worth following the LLM tolerance path.
14:46:31 s​yntheticbird:monero.social: Contributors are not just work force, they can have individual talents/idiosyncratic code that may reveal improvements. LLM-assisted contributions do not permit that
14:47:06 c​ryptagupta:matrix.org: Yes, i do have some repos where i get PR's from people who clearly don't understand what they're doing.
14:47:07 c​ryptagupta:matrix.org: But i've also received PRs from experienced developers who would not have been able to contribute without AI assistance (unfamiliarity with language or framework usually, as is the case with me here). And it's generally possible to tell the difference by being objective about the quality of the PR.
14:48:39 c​yrix126:gupax.io: > unfamiliarity with language or framework usually, as is the case with me here
14:48:41 c​yrix126:gupax.io: If you want to contribute to a project seriously, that's the first thing to correct ?
14:49:01 s​yntheticbird:monero.social: I was searching my words to say it, thanks
14:50:00 c​ryptagupta:matrix.org: yes. it was obviously AI generated (actually I edited it somewhat, the bad grammar is me :-), I certainly was not trying to hide that, otherwise i would have changed the commit / PR.
14:50:57 s​yntheticbird:monero.social: Not trying to put some sort of guilt on your shoulder, but generally there is a difference between disclosing, not telling, and hiding
14:51:03 s​yntheticbird:monero.social: not hiding != disclosing
14:51:24 c​ryptagupta:matrix.org: agreed. but wouldn't it be better to be productive while doing so.
14:52:05 c​ryptagupta:matrix.org: fair point. i would argue that the text of the description made it pretty clear that it was AI generated.
14:53:29 s​yntheticbird:monero.social: I see your point, but if I had to count at loud the number of times the obvious has been debated on matrix channels or on github, I would die of dehydration
14:56:06 c​ryptagupta:matrix.org: agreed. but wouldn't it be better to be productive while doing so.
14:57:17 s​yntheticbird:monero.social: You are not being productive
14:57:38 s​yntheticbird:monero.social: At least not the extent you believe
14:59:08 s​yntheticbird:monero.social: The correct course of actions would have been to learn rust basics, read documentation about crates features and conditional compilation, and then push out a PR by yourself. And then maybe if you're not confident ask for a maintainer to give his opinion on your branch.
14:59:21 c​yrix126:gupax.io: You'll be more productive after learning, you are limited otherwise and won't never make any important pr. And what you see now as productive can become a nightmare for other contributors.
14:59:25 s​yntheticbird:monero.social: We're always happy to help out new learners
15:00:19 r​edsh4de:matrix.org: https://rust-book.cs.brown.edu/
15:00:21 r​edsh4de:matrix.org: This is what i went through last year to learn Rust basics, together with Rustlings for practical exercises
15:45:38 c​ryptagupta:matrix.org: All your points are well taken.
15:45:39 c​ryptagupta:matrix.org: The point I was trying to make was that I worked with AI to generate a small diff. And although I am not so familiar with rust, I have worked with C (and quite a few other languages) and most of the concepts are quite familiar. So I understood the changes that were made by the LLM (again fairly simple). I also verified the code and ran all the tests before submitting the PR.
15:45:41 c​ryptagupta:matrix.org: That probably saved whoever merges it some time, so it was at least a little productive.
15:45:43 c​ryptagupta:matrix.org: I learned something about the structure of the code, as well as the contribution process.
15:45:45 c​ryptagupta:matrix.org: I think that's a good way to learn.
15:45:47 c​ryptagupta:matrix.org: Although I think AI and quality are not mutually exclusive, I can see numerous counter examples out there, so can't blame anyone who believes that. Ultimately I think it would be good to treat PRs on a case by case basis, and have the maintainers enforce quality as needed.
15:45:49 c​ryptagupta:matrix.org: Granted that banning AI aided contributions is another way to maintain quality. I guess it's up to the core group to decide how to do this going forward.
15:45:51 c​ryptagupta:matrix.org: Thank you all for your suggestions and advice.