21–30 of 320 posts
Issues simply don't scale. Using discussions as a filter is a good idea. If you spend more time closing issues than creating them manually from discussions, the math adds up.
The math is even better if you just ignore all issues and close them after two weeks for being stale!
Wish this was /s but it isn't.
Issues simply don't scale. Using discussions as a filter is a good idea. If you spend more time closing issues than creating them manually from discussions, the math adds up.
What is the actual difference? As a maintainers, if you want to be be able to tell real issues from non-issue discussions, you still gave to read them (triage). That's what's taking time. I don't see how transforming a discussion into an issue is less effort than the other way around. Both are a click. Github's issues and discussions seem the same feature to me (almost identical UI with different naming). The only po…
I agree with the general philosophy about user submissions. Browsing closed discussions looks a lot like browsing closed issues. So I'm not sure that the policy is successfully turning bug reports into discussions. But it's at least keeping Issues free from noise for contributors. Github could do more to nudge users into approaching Discussions differently. https://github.com/ghostty-org/ghostty/discussions?discussio…
The point is the opposite, AFAICT. Any user complaint starts as a discussion. If an actionable bug report results from it, it goes to the tracker, which serves as list of problems to work on. A lot of discussions do not end this way, even though they may solve a user's issue anyway, e.g. by providing advice and reference. Definitely discussing things could also happen in the issue tracker, and some tag could be used…
For example, memory leak investigation is currently spread across discussions, x/twitter and discord https://x.com/mitchellh/status/2004938171038277708 https://x.com/alxfazio/status/2004841392645050601 https://github.com/ghostty-org/ghostty/discussions/10114 https://github.com/ghostty-org/ghostty/discussions/9962 but has not graduated to issue worthy status
That's a shame to hear. I had to give up on Ghostty because of its memory leak issue. Granted, it was on an 8GB system, but that should be enough to run a terminal without memory exhaustion a few times a week. Foot has been rock solid, even though it lacks some of Ghostty's niceties.
For me, only Rust compilation necessitates more RAM. But, I assume devs just do RAM heavy dev work on a server over ssh.
Earlier quoted context omitted.
That's a shame to hear. I had to give up on Ghostty because of its memory leak issue. Granted, it was on an 8GB system, but that should be enough to run a terminal without memory exhaustion a few times a week. Foot has been rock solid, even though it lacks some of Ghostty's niceties.
btw, is it me or is there any justification for anyone including a developer to run more than 8GB of RAM for a laptop? I don't see functionality as having changed in the last 15 years. For me, only Rust compilation necessitates more RAM. But, I assume devs just do RAM heavy dev work on a server over ssh.
Issues simply don't scale. Using discussions as a filter is a good idea. If you spend more time closing issues than creating them manually from discussions, the math adds up.
What is the actual difference? As a maintainers, if you want to be be able to tell real issues from non-issue discussions, you still gave to read them (triage). That's what's taking time. I don't see how transforming a discussion into an issue is less effort than the other way around. Both are a click. Github's issues and discussions seem the same feature to me (almost identical UI with different naming). The only po…
imo almost all issues are real, including "non-issue" - i think you mean non-bug - "discussions." for example it is meaningful that discussions show a potential documentation feature, and products like "a terminal" are complete when their features are authored and also fully documented or discoverable (so intuitive as to not require documentation).
99% of the audience of github projects are other developers, not non-programmer end users. it is almost always wrong to think of issues as not real, every open source maintainer who gets hung up on wanting a category of issues narrower than the ones needed to make their product succeed winds up delegating their product development to a team of professionals and loses control (for an example that I know well: ComfyUI).
Earlier quoted context omitted.
btw, is it me or is there any justification for anyone including a developer to run more than 8GB of RAM for a laptop? I don't see functionality as having changed in the last 15 years. For me, only Rust compilation necessitates more RAM. But, I assume devs just do RAM heavy dev work on a server over ssh.
Chrome on my work laptop sits around 20-30GB all day every day.
Issues simply don't scale. Using discussions as a filter is a good idea. If you spend more time closing issues than creating them manually from discussions, the math adds up.
> If you spend more time closing issues than creating them manually from discussions, the math adds up. The math is even better if you just ignore all issues and close them after two weeks for being stale! Wish this was /s but it isn't.
If it's someone else's project, they have full authority to decide what is and isn't an issue. With large enough projects, you're going to have enough bad actors, people who don't read error messages, and just downright crazy people. Throw in people using AI for dubious purposes like CVE inflation, and it's even worse.
Earlier quoted context omitted.
That's a shame to hear. I had to give up on Ghostty because of its memory leak issue. Granted, it was on an 8GB system, but that should be enough to run a terminal without memory exhaustion a few times a week. Foot has been rock solid, even though it lacks some of Ghostty's niceties.
btw, is it me or is there any justification for anyone including a developer to run more than 8GB of RAM for a laptop? I don't see functionality as having changed in the last 15 years. For me, only Rust compilation necessitates more RAM. But, I assume devs just do RAM heavy dev work on a server over ssh.
In the SWE world, dev servers are a luxury that you don't get in most companies, and most people use their laptops as workstations. Depending on your workflow, you might well have a bunch of VMs/containers running.
Even outside of SWE world, people have plenty of use for more than 8GiB of RAM. Large Photoshop documents with loads of layers, a DAW with a bazillion plugins and samples, anything involving 4k video are all workloads that would struggle running on such a small RAM allowance.