Live data from Hacker News

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

lars.ingebrigtsen.no

31–40 of 117 posts

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

#31
post #2

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

I'm not really sure how to reply to this.

The first thing that's worth mentioning is that Emacs isn't simply in "maintenance" mode. There is a nice steady flow of new features, significant features too such as Elisp native compilation and Wayland support.

It's also important to keep in mind the sheer scale of Emacs. Vanilla Emacs ships over 1 million lines of Elisp (I'm getting 1.3m according to a small shell script). Considering just how massive of a scale this is, 3000 bugs is really not so bad.

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

#32
post #27
post #19

Earlier quoted context omitted.

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.

Yes, if the org is vehemently against it, you can create another project as a "bad bank".

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

#33
post #6

Looks like since this was posted, the page author has closed another 10% of open emacs bugs: https://lars.ingebrigtsen.no/2022/01/20/13x10/

Last update is https://lars.ingebrigtsen.no/2022/08/19/19x10/

I haven’t been following along lately, but this one has a line that made me laugh:

> And that leads to Emacs hanging if the mode’s font-lock rules hasn’t been written in a careful manner, and they mostly haven’t.

No, they mostly haven’t! That applies to so many things :D

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

#34
post #19

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?

It enables the company to get to a different level of fixing bugs. Say you have 10+bugs/engineer, it's hard to realistically lower them. So you slash the number of bugs and that enables you to implement ways to keep the bug count low: fix-bug-first, code reviews, checklists, static tools, phase injection analysis, bug council, etc.

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

#35
post #2

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

I'm not really sure how to reply to this. The first thing that's worth mentioning is that Emacs isn't simply in "maintenance" mode. There is a nice steady flow of new features, significant features too such as Elisp native compilation and Wayland support. It's also important to keep in mind the sheer scale of Emacs. Vanilla Emacs ships over 1 million lines of Elisp (I'm getting 1.3m according to a small shell script)…

Yea, that’s 3,000 open bug reports, but there are probably at least 10,000 unreported bugs in obscure modes. The really obscure ones are the most likely to be both half–finished and not used very much.

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

#36

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

The age old ostrich approach!

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

#37
post #26

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

Yes. Many old bugs are no longer there, because dozens or hundreds of features have been built since upon the buggy code.

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

#38
post #28
post #9

Earlier quoted context omitted.

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.

That was back when 8MB was not just big, but so huge that your University’s Computer Science department couldn’t afford it.

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

#39
post #36

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

The age old ostrich approach!

"and we implement ways to not reach high bug levels again"

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

#40

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.

Yes you're right, in an open source project the bug tracker helps developers understand why something doesn't work and if it's their problem or a library bug.
Post reply on HN