but has not graduated to issue worthy status
"Slop drives me crazy and it feels like 95+% of bug reports, but man, AI code analysis is getting really good. There are users out there reporting bugs that don't know ANYTHING about our stack, but are great AI drivers and producing some high quality issue reports.
This person (linked below) was experiencing Ghostty crashes and took it upon themselves to use AI to write a python script that can decode our crash files, match them up with our dsym files, and analyze the codebase for attempting to find the root cause, and extracted that into an Agent Skill.
They then came into Discord, warned us they don't know Zig at all, don't know macOS dev at all, don't know terminals at all, and that they used AI, but that they thought critically about the issues and believed they were real and asked if we'd accept them. I took a look at one, was impressed, and said send them all.
This fixed 4 real crashing cases that I was able to manually verify and write a fix for from someone who -- on paper -- had no fucking clue what they were talking about. And yet, they drove an AI with expert skill.
I want to call out that in addition to driving AI with expert skill, they navigated the terrain with expert skill as well. They didn't just toss slop up on our repo. They came to Discord as a human, reached out as a human, and talked to other humans about what they've done. They were careful and thoughtful about the process.
People like this give me hope for what is possible. But it really, really depends on high quality people like this. Most today -- to continue the analogy -- are unfortunately driving like a teenager who has only driven toy go-karts."
"Examples: https://github.com/ghostty-org/ghostty/discussions?discussio... "
The real miss here is that there isn't a way on GitHub to only allow maintainers to create issues, instead we are left with these subpar workarounds.
[1]: https://github.com/LGUG2Z/komorebi/blob/master/.github/workf...
I reported the issue in discussions some time ago, but had no reaction/response.
I was able to reproduce the leak consistently. Finally I've got all the reports done by me, Ghostty sources and Claude Code and tried to fix it.
For the first couple of weeks there were no leaks at all, now it started again but only 1/10 of the times it was before.
https://github.com/ghostty-org/ghostty/discussions/9786 There are some logs and a Claude Code review md file that might be useful.
Hope it will help someone investigate further.
macOS' Instruments tool only checks for leaks when it can track allocations and it is limited to ~256 stack depth. For recursive calls or very deep stacks (Emacs) some allocations aren't tracked and only after setting malloc history flags [0] I started seeing some results (and leaks).
Another place I'm investigating (for Emacs) is that AppKit lifecycle doesn't actually align with Emacs lifecycle and so leaks are happening on the AppKit and that has ZERO to do with application. Seems that problem manifests mostly on a high end specs (multiple HiDPI displays with high variable refresh rate, powerful chip etc.)
Probably nothing you haven't investigated yet, but it is similar to the ghost (pun intended) I've been looking for.
[0]: https://developer.apple.com/library/archive/documentation/Pe...
site:https://github.com/org/repo key wordsAbove, the word _simply_ conveys a lot of meaning. This sentence, when considered alone, might be seen to imply that all trade-offs are in a sense, ok, because they are all sort of a matter of taste. This doesn't mesh with my understanding of the world. I frame it this way: for a given objective, some trade-offs are better than others.
Put in reverse, when I see a project making certain trade-offs, I don't assume those trade-offs are in service of some clearly defined objective. Often I see people and organizations mired in trade-offs that are inertial and/or unconsidered.
There is another interesting angle to consider: framing as a question it would be: «When building a product or running a project, how do I make sense of a huge variety of trade-offs?» For that, exploring the Pareto frontier can be a useful method (see [1]) because it reduces the combinatorial explosion.
In the case of Ghostty, I think its values are indeed better served by this GitHub process (which designates an issue as a clear actionable task derived from a discussion).
1. We often say 'should' too easily. The post isn't making such a claim is it? I would shift away from saying 'should' to saying: start somewhere that works for your project, gather feedback and evidence, and adjust thoughtfully. You'll end up in a place that feels authentic.
2. If anything, I would prefer the default be random. Then projects end up being natural experiments. See [1]
3. At a meta level, this reminds me of Brian:
> Brian: Look, you've got it all wrong! You don't need to follow me. You don't need to follow anybody! You've got to think for yourselves! You're all individuals!
> Crowd: Yes! We're all individuals!
> Brian: You're all different!
> Crowd: Yes, we are all different!
> Man in crowd: I'm not...
> Crowd: Shhh!
I'm not so sure. I think this sort of discussion mostly falls within the realm of bike shedding. I'll explain why.
There's such a thing as a ticket life cycle. Ticketing flows typically feature a triage/reproduction stage. Just because someone creates an issue that doesn't necessarily mean the issue exists or isn't already tracked somewhere else, or that the ticket has all the necessary and sufficient information to troubleshoot an issue. When a ticket is created, the first step is to have someone look at it and check if there's something to it. This happens even when tickets are created by internal stakeholders, such as QAs.
GitHub supports ticket labels, and the default set already cover these scenarios.
https://docs.github.com/en/issues/using-labels-and-milestone...
To me this discussion sounds like a project decided to update their workflow to move triage out of tickets and into a separate board. That's fine, it's the exact same thing but with a slightly more complex process. But it's the same thing.
(also, what is "huge success" in methods of organizing issues?)
bookmark: (and if your browser supports shortcuts, it can be as easy to open as remembering to type a single char)
https://github.com/ghostty-org/ghostty/issues?q=is%3Aissue%2...
With sufficient thrust, pigs fly just fine. However, this is
not necessarily a good idea. It is hard to be sure where they
are going to land, and it could be dangerous sitting under them
as they fly overhead.
You are not describing a network issue. You're sending requests that by design the origin servers refuse to authorize. This is basic HTTP.
https://datatracker.ietf.org/doc/html/rfc7231#page-59
The origin servers could also return 404 in this usecase, but 403 is more informative and easier to troubleshoot, because it means "yeah your request to this resource could be good but it's failing some precondition".