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

21–30 of 117 posts

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

#21

Post by dj_mc_merlin »

gspr wrote: post #19
KingOfCoders wrote: post #16

Little bit related: When I come into a company as CTO, and there are too many bugs, I just close all bugs older than 6 months. Usually that's more than 10% (and the org wasn't capable or willing to fix them). Hasn't created any problems yet, but everyone feels better immediately (and we implement ways to not reach high bug levels again).

Wh... why?

> the org wasn't capable or willing to fix them

Probably this. Can't fix everything, and the bugs piling up demoralizes many engineers. Six months is a bit low, I'd go higher, but there's no point having a bug on your board that you're not realistically actually going to fix.

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

#22

Post by matthews2 »

okamiueru wrote: post #12

Unrelated to the echievent the article mentions. But I'm curious, how does emacs fare for modern C++ these days? Is it a good IDE? It always struck me that an editor with the history it has, couldn't handle C++11 syntax in 2014. Or, I didn't want to try to figure out how. To clarify, I include common packages as part of "out of the box". From a quick Google search, it does look like cc-lang might be catching up. And…

I don't really have any trouble using Emacs on the "modern" C++ codebases that I'm working on. I've tried lsp-mode and eglot with clangd but found that really all I need is a little bit of elisp to call clang-format, dumb-jump (https://github.com/jacktasia/dumb-jump>) to jump to definition, and project-compile to build the project and collect warnings/errors into a buffer.

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

#23

Post by rad_gruchalski »

gspr wrote: post #19
KingOfCoders wrote: post #16

Little bit related: When I come into a company as CTO, and there are too many bugs, I just close all bugs older than 6 months. Usually that's more than 10% (and the org wasn't capable or willing to fix them). Hasn't created any problems yet, but everyone feels better immediately (and we implement ways to not reach high bug levels again).

Wh... why?

Because if they’re not resolved yet, there’s no client suffering from them in short term. If they suffer from such a bug, someone will raise it again.

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

#24

Post by ycombinete »

okamiueru wrote: post #12

Unrelated to the echievent the article mentions. But I'm curious, how does emacs fare for modern C++ these days? Is it a good IDE? It always struck me that an editor with the history it has, couldn't handle C++11 syntax in 2014. Or, I didn't want to try to figure out how. To clarify, I include common packages as part of "out of the box". From a quick Google search, it does look like cc-lang might be catching up. And…

A company I worked at handled a massive c++ code base, and nearly all the devs used Emacs as their main editor. That was back in like 2012.

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

#25

Post by ZephyrBlu »

gspr wrote: post #19
KingOfCoders wrote: post #16

Little bit related: When I come into a company as CTO, and there are too many bugs, I just close all bugs older than 6 months. Usually that's more than 10% (and the org wasn't capable or willing to fix them). Hasn't created any problems yet, but everyone feels better immediately (and we implement ways to not reach high bug levels again).

Wh... why?

Can imagine it's for a lot of reasons. Like:

- Improves morale

- Focuses the team

- Makes the task more approachable

Etc.

The important ones will probably bubble up again in due time.

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

#26

Post by neilv »

KingOfCoders wrote: post #16

Little bit related: When I come into a company as CTO, and there are too many bugs, I just close all bugs older than 6 months. Usually that's more than 10% (and the org wasn't capable or willing to fix them). Hasn't created any problems yet, but everyone feels better immediately (and we implement ways to not reach high bug levels again).

On the theory that the valid and important enough bugs would've been fixed within 6 months?

Any idea the breakdown of the bugs that were closed?

(Guesses at percentages of which were user error, applied only to an older version, duplicates, irreproducibile, valid but would happen only in freak circumstances, low impact, etc.)

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

#27

Post by eru »

gspr wrote: post #19
KingOfCoders wrote: post #16

Little bit related: When I come into a company as CTO, and there are too many bugs, I just close all bugs older than 6 months. Usually that's more than 10% (and the org wasn't capable or willing to fix them). Hasn't created any problems yet, but everyone feels better immediately (and we implement ways to not reach high bug levels again).

Wh... why?

You can just archive the bugs somewhere, so you can open them again later if you want to. (You don't need to completely delete them or so.)

I can see how this can provide psychological benefits to some people.

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

#28

Post by eru »

makach wrote: post #9
AlchemistCamp wrote: post #7

Earlier quoted context omitted.

Just wait until you see how many bugs VS Code has!

I love VS Code, but I occasionally wonder; should we be amazed over its resilience or in awe that it actually works? I can't decide. also, every time I think about the amount of CPU cycles that has to be executed just for the first pixel to appear on the screen, just, wow. what a time to be alive!

People used to think that Emacs was bloated. Like:

'Eight Megabytes (of RAM) And Constantly Swapping', back when 8 MiB was big.

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

#29

Post by account42 »

KingOfCoders wrote: post #16

Little bit related: When I come into a company as CTO, and there are too many bugs, I just close all bugs older than 6 months. Usually that's more than 10% (and the org wasn't capable or willing to fix them). Hasn't created any problems yet, but everyone feels better immediately (and we implement ways to not reach high bug levels again).

This might be an OK strategy for an internal bug tracker but for an open source project or something else with a public bug tracker just closing unresolved bugs is the best way to alienate your most dedicated users who have taken the time to file bug reports.

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

#30

Post by asah »

Animats wrote: post #2

After 39 years of EMACS maintenance, having over 3000 bugs is embarrassing.

After 39 years of EMACS maintenance, having ONLY 3000 bugs is AMAZING.

---

FTFY: most commercial software projects get 3,000 bugs in 3-5 years (if they're successful and grow), and you quickly need a serious database (e.g. jira) to curate them. It's not a morale issue because there's product manager(s) who manage this herd, not eng, and there's no expectation of zero defects because the goal is to win marketshare, which is far removed from any individual bug.

Post reply on HN