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

My goal of closing 10% of Emacs bugs (2020)

lars.ingebrigtsen.no

Post reply on HN
Print view View original

111–117 of 117 posts

Re: My goal of closing 10% of Emacs bugs (2020)

#111

Post by ZephyrBlu »

gspr wrote: post #103
KingOfCoders wrote: post #83

Earlier quoted context omitted.

> I'd buy this if the bug was actually gone. But it's not! Closing a bug report doesn't make the bug go away! It does improve morale. Developers see a mountain of bugs they could never fix. > I don't understand. Can you elaborate? Say you have 100 bugs open for 10 developers, and you close all bugs older than 6 months. Then you go through the remaining one and close all the ones who have no impact ("css line should b…

> It does improve morale. Developers see a mountain of bugs they could never fix. So you propose that telling them that the mountain is gone will actually make them believe that it is? > No managing hundreds of bugs in a bugtracker that do not get fixed is a terrible waste of everyone's time. How do bug tracker entries waste people's time? Sure, confirming or fixing or otherwise working on a bug takes time, but that'…

> So you propose that telling them that the mountain is gone will actually make them believe that it is?

Yes... at least in the short term.

Think about seeing 100 issues vs 1000 issues. 1000 issues is clearly more demotivating. It's also a lot harder to tackle because of the sheer amount. You don't have enough time to fix all of them, so how to do you prioritize and distribute the work? With 100 issues you can get stuck in much quicker and prevent those 1000 issues from stacking up again.

> How do bug tracker entries waste people's time? Sure, confirming or fixing or otherwise working on a bug takes time, but that's hardly wasted. And if the bug just sits there, how does it waste time?

How many bugs do not have payoff proportional to the time spent triaging and working on them? Probably most. Cutting a whole lot of issues probably makes the 'right' decision for >50% of them.

Re: My goal of closing 10% of Emacs bugs (2020)

#112

Post by KingOfCoders »

bee_rider wrote: post #108
KingOfCoders wrote: post #97

Earlier quoted context omitted.

"Some of the oldest unclosed bug reports are the most valuable. because they document long-standing pain points." Say there is a bug, "The line should be 2 em high" and the bug is not fixed for 6+ months, how is this more valuable because it's older? Yes, I would agree with the triage, and do it if possible. If an organisation is unwilling to spend resources to fix bugs, a triage doesn't work. It's the same with this…

"The line should be 2 em high" seems more like a feature request or... like just a general whining, than a bug. Your strategy of just closing these is probably valid. But I would call it "closing non-bug complaints which abuse the bug tracker," not slashing bugs. The reason people are so confused here, I think, is because to programmers, bugs are incorrect behavior of the program. These bugs exist whether they are re…

"is because to programmers"

You might be overgeneralizing, I have been coding for 40+ years, maintained several successful open source projects, fixed many bugs, created even more, wrote bug reports and have a Go IDE open right now.

Re: My goal of closing 10% of Emacs bugs (2020)

#113

Post by kleiba »

KptMarchewa wrote: post #55
kleiba wrote: post #51

I saw somebody on Reddit describing reading the Emacs documentation as being forced to read an academic treatise… and I sympathise. I think thorough documentation is important, but sometimes you don’t want to read about all the subtleties and edge cases, but just want a I HAVE A STRING HERE JUST FUCKING TELL ME WHAT TO DO WITH IT list of functions. I couldn't disagree more. I've done tons of Emacs lisp programming ov…

Reference vs documentation. First you need to find "shape" of thing that you're actually want to use in your current problem. Bunch of examples are the best aid here. If you find whatever you want, then it's time to understand all the subtleties.

But isn't that exactly how Emacs' documentation is organized? For each topic, you get an entry page that gives an overview, followed by a more detailed API documentation.

Re: My goal of closing 10% of Emacs bugs (2020)

#114

Post by everforward »

mpol wrote: post #88
KingOfCoders wrote: post #86

Earlier quoted context omitted.

Usually people don't quit when I join and are rather happy that problems are solved instead of not solved. I would also not sit at my desk one day, and close all the bugs - but talk to developers, managers, leads, QA and product on how we solve the bug problems together. Slashing the number of bugs in the bugtracker is only one task and people didn't object but agreed to it as a way forward. I created by first bugs 4…

> ...rather happy that problems are solved instead of not solved. But they are not solved, are they? > With the slashing of the bugs... And it's not slashing bugs, but slashing bug reports. The bugs are still there.

I would say that closing the bugs as WONTFIX is just changing the specs of the application so it's not a bug anymore.

E.g. if you've got a bug that emojis cause an endpoint to throw a 500, closing the bug as WONTFIX is akin to just saying that emojis are invalid input to the application.

After 6 months or a year, that's how everyone is treating it anyways.

Re: My goal of closing 10% of Emacs bugs (2020)

#115

Post by karthink »

kleiba wrote: post #51

I saw somebody on Reddit describing reading the Emacs documentation as being forced to read an academic treatise… and I sympathise. I think thorough documentation is important, but sometimes you don’t want to read about all the subtleties and edge cases, but just want a I HAVE A STRING HERE JUST FUCKING TELL ME WHAT TO DO WITH IT list of functions. I couldn't disagree more. I've done tons of Emacs lisp programming ov…

> I HAVE A STRING HERE JUST FUCKING TELL ME WHAT TO DO WITH IT

M-x shortdoc-display-group string

Re: My goal of closing 10% of Emacs bugs (2020)

#116

Post by bhrgunatha »

gjadi wrote: post #58
krmboya wrote: post #57

Earlier quoted context omitted.

For experts, a comprehensive manual is useful. For beginners, or people who occasionally dabble in elisp for some light customisation work, a whole treatise in elisp programming is probably an overkill

Well, that's why there is several documents: C-h i * Elisp: (elisp). The Emacs Lisp Reference Manual. * Emacs Lisp Intro: (eintr). A simple introduction to Emacs Lisp * Emacs: (emacs). The extensible self-documenting text editor. * Emacs FAQ: (efaq). Frequently Asked Questions about Emacs. And that's not even looking at specialized documentation such as the one for Gnus, for Widget, for Dired-X, for Ediff, ... I agre…

The introspection via all the commands bound to C-h is a major thing I miss from any other system. That includes the ability to view and debug the source code - including the base level commands written in C if you've configured it to do so.

Plus, it's all right there _in emacs_ with all its facilities and your customisations while you're using it.

Re: My goal of closing 10% of Emacs bugs (2020)

#117

Post by bee_rider »

KingOfCoders wrote: post #112
bee_rider wrote: post #108

Earlier quoted context omitted.

"The line should be 2 em high" seems more like a feature request or... like just a general whining, than a bug. Your strategy of just closing these is probably valid. But I would call it "closing non-bug complaints which abuse the bug tracker," not slashing bugs. The reason people are so confused here, I think, is because to programmers, bugs are incorrect behavior of the program. These bugs exist whether they are re…

"is because to programmers" You might be overgeneralizing, I have been coding for 40+ years, maintained several successful open source projects, fixed many bugs, created even more, wrote bug reports and have a Go IDE open right now.

So do you disagree with my definition of a bug?
Post reply on HN