alexrp

This framing is weird; this kind of lobbying through campaign/party donations happens almost anywhere that elections are a thing.

> My point is that at some point one needs to recognize their project is used for production stuff and make stability the focus, rather than hiding behind the 0.x excuse for years. Call it the Peter Pan syndrome of open source.

We have a roadmap to 1.0.0 -- it's literally right there in the release notes -- and we're going to execute on that and then tag it. Ignoring that (and SemVer) and declaring that we should actually stabilize right now is a bit unreasonable.

> For comparison, Elixir started in 2012, and got its 1.0 in 2014, two years later. Zig stable has been ‘a few years’ for literally a decade.

This is a wild comparison to me, and I say this as someone who actually used Elixir for a time fairly early in its development (and still like it!). Zig has a vastly larger and more difficult problem space to deal with than Elixir.

> after 2 times consecutively facing the same issue

Sorry, would you mind clarifying what you mean by this? I'm only aware of the one incident?

Well of course the block itself was deliberate. By "in error" I meant that we might have misjudged the text as being LLM.

Who did you email, when, and did you get a response? We've all been very busy leading up to the release, and most of the team is also currently traveling for SYCL.

Regarding sending a message, consider our side: We're tired of having our time wasted on slop, so we don't also want to have to write formal block notifications to people we block on suspicion of using LLMs. I'm fully aware that this can lead to an unfortunate situation like this, however. For what it's worth, this is why we want to move to an invite tree for Zig development; it'll allow us to create a high-trust environment where this kind of suspicion is unnecessary.

I would suggest just starting by filling out the bug report template, i.e. steps to reproduce, expected behavior, and observed behavior. If for some reason you can't provide a reasonable reproduction, the symptoms on their own can sometimes be enough for us to make an educated guess at what's going wrong.

Regarding whether you should post the root cause analysis: Per the current policy, the answer would have to be no.

I do personally have more nuanced thoughts on this, and I started typing them out... but then I realized that my reply was getting dangerously close to blog post length, so I decided to restrain myself and commit to turning it into an actual blog post later. In a nutshell, though, the problem is that even if there is such a thing as responsible use of LLMs for bug analysis, the only way we can currently be confident that someone possesses the required qualities for that is by working with them for a while.

Yes, 0.16.0 and 0.17.0 are the only two releases that have loop vectorization disabled. (And it will be re-enabled in 0.18.0.)

> because my projects on github using zig uses LLM

To be clear, we do not block people for merely having LLM-related projects. Obviously we have opinions about LLMs in a broader context, but in terms of rules enforcement, we only care about LLM usage taking place within official Zig spaces.

It's possible you were blocked in error. LLM detection is not foolproof, so unless it's an open-and-shut case, our usual approach is to just unblock if people reach out to us by email.

We simply ask that Zig bug reports be written by humans, for humans. Whether you use LLMs on your project is immaterial to us.

Yes, I'm a core team member.

> If there's an edict that no one is allowed to bring up the topic, how can someone change this part of the code of conduct?

To clarify, do you mean someone who isn't part of the core team?

For the record, there isn't even uniformity of thought on LLMs within the core team, let alone the broader Zig community.

The fix could not be backported to LLVM 22 because it changed the LLVM library ABI. We also could not skip straight to LLVM 23 because that would make life harder for distro package maintainers.

I think it depends on location.

It would be a bizarre approach in Scandinavia because the consensus here is that companies must pay their employees a decent baseline salary -- which unions negotiate across the whole sector -- so there's no expectation of a tip by default.

But for much of the rest of the world, it's not a given that working conditions are as good.

> But you cannot state that people are "welcome to engage and debate the idea on its merits" when that clearly isn't the case.

I really didn't think that part had to be stated explicitly; I genuinely don't know why someone not invested in Zig would even feel the need to go debate on the Zig issue tracker. But even setting that aside, this is far from the first time that the core team has made it clear that we don't want the internet peanut gallery to brigade the issue tracker.

> as evidenced by real comments being deleted from that issue.

Which real comments were deleted?

You don't need to be a Zig expert, but you do need to at least be invested in the Zig ecosystem in some way.

I think it's reasonable for any open source project to only be interested in the opinions of its actual users, especially when obvious social media brigading is taking place.

If I -- having written precisely 5 lines of Rust in my life -- showed up on the Rust issue tracker and started expressing my opinions on the future direction of the project and debating a proposed feature, I would absolutely expect people to be annoyed about the noise I'm generating.

The Zig issue tracker is for technical discussion; you are more than welcome to engage and debate the idea on its merits. But we do indeed delete meta-commentary, wild speculation, and outright hostility.