Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why users cannot create Issues directly

github.com

Post reply on HN
Print view View original

201–210 of 320 posts

Re: Why users cannot create Issues directly

#201

Post by School-Cotton »

favflam wrote: post #24
quantummagic wrote: post #8

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.

> But, I assume devs just do RAM heavy dev work on a server over ssh.

This assumption is wrong. I compile stuff directly on my laptop, and so do a lot of other people.

Also, even if nobody ran compilers locally, there is still stuff like rustc, clangd, etc. which take lots of RAM.

Re: Why users cannot create Issues directly

#202

Post by quotemstr »

Maxious wrote: post #6

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

It's not clear to me why I'd want to use Ghostty over WezTern or Kitty, TBH. Ghostty is certainly trends on social media, but that's a negative signal for me.

Re: Why users cannot create Issues directly

#203

Post by fastasucan »

favflam wrote: post #24
quantummagic wrote: post #8

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.

>But, I assume devs just do RAM heavy dev work on a server over ssh.

Why do you assume that? Its nice to do things locally sometimes. Maybe even while having a browser open. It doesn't take much to go over 8gb.

Re: Why users cannot create Issues directly

#204

Post by eviks »

mitchellh wrote: post #65
eviks wrote: post #10

> This pattern makes it easier for maintainers or contributors to find issues to work on since every issue is ready to be worked on. How is this not trivially solved via a "ready-to-be-worked-on" tag?

Because I don't want my default view to be "triage." If GitHub allowed default issue views (and reflected that in the issue count in the tabs as well), then maybe. But currently, it doesn't work. I've tried it at large project scale across many (multiple projects with more than 20K stars and millions of downloads). Compared to that, this system has been a huge success. It has its own problems, but it's directionally…

How does different count affect search? You can use a bookmark to change the view, and if using bookmarks is too much, ok, but that's not a bold universal reason.

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

Re: Why users cannot create Issues directly

#205

Post by eqvinox »

codeflo wrote: post #124
throwaway81523 wrote: post #104

Earlier quoted context omitted.

The trouble here is that github issues is crap. Most bug trackers have ways to triage submissions. When a rando submits something, it has status "unconfirmed". Developers can then recategorize it, delete it, mark it as invalid, confirm that it's a real bug and mark it "confirmed", etc. Github issues is mostly a discussion system that was so inadequate that they supplemented it with another discussion system.

> Most bug trackers have ways to triage submissions. When a rando submits something, it has status "unconfirmed". Developers can then recategorize it, delete it, mark it as invalid, confirm that it's a real bug and mark it "confirmed", etc. As far as I'm aware, most large open GitHub projects use tags for that kind of classification. Would you consider that too clunky?

> As far as I'm aware, most large open GitHub projects use tags for that kind of classification. Would you consider that too clunky?

Speaking for another large open GitHub project:

Absofuckinglutely yes.

I cannot overstate how bad this workflow is. There seems to be a development now in other platforms becoming more popular (gitlab, forgejo/codeberg, etc.) and I hope to god that it either forces GitHub to improve this pile of expletive or makes these "alternate" platforms not be so alternate anymore so we can move off.

Re: Why users cannot create Issues directly

#206

Post by eqvinox »

Aurornis wrote: post #189
asdfaoeu wrote: post #149

Earlier quoted context omitted.

This still puts the onus on the developers to categorise the issues which I'm guessing they don't want to do.

There are several automation solutions for GH issues. You could have an automatic “unconfirmed” tag applied to every user-created issue if you wanted.

RFC1925¹, section 2(3):

  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.
Translation: sure, you can make this work by piling automation on top. But that doesn't make it a good system to begin with, and won't really result in a robust result either. I'd really rather have a better foundation to start with.

¹ https://www.rfc-editor.org/rfc/rfc1925

Re: Why users cannot create Issues directly

#207

Post by fastasucan »

typeofhuman wrote: post #27
tynorf wrote: post #25

Earlier quoted context omitted.

Chrome on my work laptop sits around 20-30GB all day every day.

I wonder if having less RAM would compel you to read, commit to long term memory, and then close those 80 tabs you have open.

Thats a weird assumption to make.

Re: Why users cannot create Issues directly

#208

Post by IshKebab »

asdfaoeu wrote: post #149
codeflo wrote: post #124

Earlier quoted context omitted.

> Most bug trackers have ways to triage submissions. When a rando submits something, it has status "unconfirmed". Developers can then recategorize it, delete it, mark it as invalid, confirm that it's a real bug and mark it "confirmed", etc. As far as I'm aware, most large open GitHub projects use tags for that kind of classification. Would you consider that too clunky?

This still puts the onus on the developers to categorise the issues which I'm guessing they don't want to do.

They're already doing that by moving discussions to issues. In fact it's more work for them because they have to actually create the issue instead of just adding a "confirmed bug" label or whatever.

I guess it probably leads to higher quality issue descriptions at least, but otherwise this seems pretty dumb and user-hostile.

Post reply on HN