← Back to context

Comment by lelanthran

7 hours ago

> What’s the point in debating the PR quality?

Because the pro-group are whining that the policy is preventing the merge, when in actual fact even if the policy did not exist, the PR is crap anyway.

16 comments

lelanthran

Reply
daishi55  3 hours ago

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.

  • greggyb  2 hours ago

    > 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.

    That may be the case, but the bun project only needs zig to correctly compile bun. The zig project needs to be able to correctly compile all existing and possible zig programs.

    I haven't reviewed things, but it's possible and even likely (at least based on my own experience with LLMs) that the validation is mostly focused on bun compilation.

  • moregrist  34 minutes ago

    > 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.

    The PR is probably fine for bun’s purposes. That doesn’t make it a good PR for Zig’s purposes, and could very well paint Zig into a weird corner.

    > It cannot be merged no matter how good it is, due to the strict no-LLM policy.

    This is about meta-discourse. Of course it’s against the policy. That’s the point of discussing the PR: to get Zig to change the policy, or at least provide an exception in this case. Or to argue the opposite.

Aeolun  7 hours ago

Of course the policy is preventing the merge. That’s literally the point of the policy…

  • lelanthran  7 hours ago

    > 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.