| |
| ▲ | daishi55 an hour ago | parent | next [-] | | I don’t see how it could be that bad (incorrect, specifically), considering bun is probably the most widely-used production use case of zig. But regardless, let’s say it’s a bad PR for the sake of argument - it’s beside the point. It cannot be merged no matter how good it is, due to the strict no-LLM policy. | |
| ▲ | an hour ago | parent | prev | next [-] | | [deleted] | |
| ▲ | Aeolun 6 hours ago | parent | prev [-] | | Of course the policy is preventing the merge. That’s literally the point of the policy… | | |
| ▲ | lelanthran 5 hours ago | parent [-] | | > Of course the policy is preventing the merge. That’s literally the point of the policy… In this case it isn't the blocker - the fact that the dev took the time to read the PR in detail, comment on it, and provide reasons why it could not be merged makes it very clear to me that the policy wasn't the blocker. If they were going to enforce the policy for this PR, they wouldn't have bothered to read it. The only reason to read it is to see if the policy is waived for this specific PR. | | |
| ▲ | baq 5 hours ago | parent [-] | | OTOH why bother to polish the PR if it won't get accepted anyway? | | |
| ▲ | lelanthran 5 hours ago | parent [-] | | > OTOH why bother to polish the PR if it won't get accepted anyway? As the Zig maintainer so patiently explained, no amount of "polish" can fix the PR because it is misaligned to the correctness that they require. IOW, that PR is so far off the reservation, unless it is completely rewritten, it won't be accepted. | | |
| ▲ | baq 3 hours ago | parent [-] | | it could have been rewritten, rewriting PRs is cheap today, but that isn't the question. the question is, would it have been accepted had it met all the quality and engineering standards and full disclosure that it was 90%+ LLM generated? | | |
| ▲ | nicoburns 2 hours ago | parent | next [-] | | > it could have been rewritten, rewriting PRs is cheap today Rewriting PRs with LLMs is cheap, but often the output is no better than the previous revision (fixing one issue only to cause another one is very common IME). And reviewing each revision of the PR is not cheap. I've had good experiences with people submitting AI generated PRs who then actually take the time to understand what's going on and fix issues (either by hand or with a targeted LLM generated fix) that are brought up in review. But it's incredibly frustrating when you spend an hour reviewing something only to have someone throw your review comments directly back at the LLM and have it generate something new that requires another hour of review. | |
| ▲ | lelanthran 3 hours ago | parent | prev [-] | | > it could have been rewritten, rewriting PRs is cheap today, but that isn't the question. the question is, would it have been accepted had it met all the quality and engineering standards and full disclosure that it was 90%+ LLM generated? In this case it looks like the answer is "Yes"; the PR was not dismissed immediately, it was first examined in great detail! Why would the maintainer expend effort on something that was going to be rejected anyway? | | |
| ▲ | baq 3 hours ago | parent [-] | | because the policy is clearly 'reject' and yet significant time has been spent - either effort was wasted or policy is at best 'not implemented'. | | |
| ▲ | lelanthran 2 hours ago | parent [-] | | > either effort was wasted or policy is at best 'not implemented'. I don't understand this PoV - have you ever come across a policy in any environment that wasn't subject to case-by-case exceptions? Even in highly regulated environments (banking/fintech, Insurance, Medical, etc), policies are subject to exceptions and exemptions, done on a case-by-case basis. The notion, in this specific case, that "well they rejected it because of policy" is clearly nonsense and I don't understand why people are pushing this so hard when the explanation of why an exemption can't be made for this specific PR is public, accessible and, I feel, already public knowledge. |
|
|
|
|
|
|
|
|
