23 ms·

This was achieved also by ignoring open issues and simply closing the bug even though the issue still exists. An example of this is: https://debbugs.gnu.org/cg

by triska 5y ago

This was achieved also by ignoring open issues and simply closing the bug even though the issue still exists. An example of this is: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21526 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21526 In general, I find too much emphasis is now on "closing" an issue as soon as possible. I understand that open issues can be a burden for maintainers. However, filing issues, especially making them reproducible, can also be a burden to users, and users will stop filing issues if too many of them are closed unilaterally without actually correcting the root cause. As I remember it, the Emacs maintainers used to put a lot more emphasis on actually correcting issues instead of only closing them, and this may also be the reason why fewer issues are reported now. A great attraction of Emacs is how easily one can actually report issues, using Emacs itself: M-x report-emacs-bug RET.

tpmx 5y ago
146 messages in that bug thread. Wow.
- irrational 5y ago
  > I'm going to go ahead and guess that the problems discussed were fixed, and I'm closing this bug report. If only there was a way to find out, instead of guessing. I’m going to start trying this at work. I wonder how it will be received?
  - jerrysievert 5y ago
    I’m going to guess that when you close issues that are years old, a fraction of them will reappear as enough people have devised workarounds for the issues and they will become the de facto fix.
  - namdnay 5y ago
    > I’m going to start trying this at work. I wonder how it will be received? You’ve never done that at work? In every company I’ve worked for, nobody would bat an eyelid at dropping an issue that hasn’t been touched for more than a year
    - nsizx 5y ago
      That's how we got that stupid bot on GitHub that constantly says "comment here or I'll close this". From time to time I have to waste my time that way. I wonder if this means maintainers want us all day bumping bugs?
      - arthur2e5 5y ago
        I have this “ready with tests” PR for almost a year now, and every time I get a notification it’s either the bot or someone who really wants the PR to be merged bumping it up for me. I don’t even care so much about it any more…
    - deleted 5y ago
      [deleted]
    - irrational 5y ago
      Without testing to see if it is actually fixed? Never. Though, to be honest, it is QA who is testing it, not us developers. But, only QA can close a ticket and no way would they close it without being 100% sure it is fixed.
      - phkahler 5y ago
        For QA to test tell if it's fixed, they must have a test case. If there is a test case here, the devs wouldn't have to guess?
        joshuaissac 5y ago
        The bug reproduction steps (along with expected vs actual behaviour) are in the opening comment of the bug report, so they really should not have had to guess.
        irrational 5y ago
        See my response to kortilla above.
      - 5y ago
  - taeric 5y ago
    Yeah... This actually seems standard for old backlogs. Were all problems fixed? Almost certainly not. Many will have become overcome by events, though. The ones that are still pertinent will reopen. Such that anytime I see a large percentage of bugs closed like this, this reflects more on working in the ticketing system than it does on fixing the problem it is managing.
  - toast0 5y ago
    When I worked for Facebook, the had a bugtracker bot that closes open issues after 6? months of no activity. It's sort of nice, but also terrible.
  - aprdm 5y ago
    I’ve done this at work many times, it’s the only way I’ve found to keep a big project back log under control… if people care enough they can reopen
  - thrower123 5y ago
    Everybody does this, it's the normal behavior with enterprise bugs. They report something. You badger them for six weeks to collect enough information to reproduce it. You fix the problem and slate it into a release and make it available. They don't take the release for another seven months.
6AA4FD 5y ago
This has always been my problem with emacs. The basic interpreter and interface design is phenomenal, but it is so bogged down and buggy it is frustrating to actually push it to the limits of capability. I wish the devs would just drop support for stuff that can be maintained just as well as a plugin.
- yjftsjthsd-h 5y ago
  Time for a neomacs?
agumonkey 5y ago
It's super sad considering the new stream of users of all levels, but energy is spent at the higher layers (emacs config, org tricks) rather than core..
- 6AA4FD 5y ago
  This is probably because it is relatively easy to add more elisp flourishes, another seven major modes for editing JavaScript, much harder to actually improve the core.
  - shadowgovt 5y ago
    As with any large system, improvements to core also risk compromising large, popular packages.
  - agumonkey 5y ago
    I wonder how remacs guys are doing now
    - the-smug-one 5y ago
      They're no longer taking PRs, development has moved over to emacs-ng with a different perspective on how to improve Emacs.
- fanf2 5y ago
  There's a new elisp JIT in emacs 28 https://emacsconf.org/2020/talks/38/ https://emacsconf.org/2020/talks/38/ There's a new portable undump in emacs 27 https://www.masteringemacs.org/article/whats-new-in-emacs-27-1 https://www.masteringemacs.org/article/whats-new-in-emacs-27... a couple of examples of very core features off the top of my head
  - agumonkey 5y ago
    I had no idea about the new JIT but in any case it would be nice if more manpower was allocated on fixing bugs I guess.
mhils 5y ago
Last message in the thread: > I'm going to go ahead and guess that the problems discussed were fixed, and I'm closing this bug report. If there's anything more to be worked on here, please send a mail to the debbugs address and we'll reopen the bug report. I don't think this really qualifies as "ignoring". Having read the last two messages or so, their approach looks totally reasonable to me. Please don't scold maintainers for cleaning up? :(
- thrdbndndn 5y ago
  I'm kind of on the fence for these (in general, not specific to this ticket). Assuming the STR is clear, is it the original reporter's responsibility, or the developer's, to confirm if a bug is fixed or not?
  - xdfgh1112 5y ago
    No other approach is sustainable.
    - jfrunyon 5y ago
      Really? You think that expecting a user who submitted a bug report five years earlier to still have patience to interact with it is sustainable?
      - ReverseCold 5y ago
        Maybe if the bug is important, someone else will reply to confirm? That could be a reasonable line of thinking.
        Chilinot 5y ago
        Yea, if a bug has been open without further discussion for 5 years then i would too take for granted that the issue is no longer an issue and close it.
        mpweiher 5y ago
lixtra 5y ago
The last message 6 years ago reads that the dev thinks the bug is fixed. Since then no-one complained. Do you know that the bug was falsely closed? Isn’t it more an example of a bug submitter loosing interest in their bug? Disclaimer: I did not read all 146 messages.
- jodrellblank 5y ago
  The person you are replying to here (triska) is the original bug opener Markus Triska. A skim read of the thread, there's a long back-and-forth of Prolog parsing and formatting and interaction with Emacs movements, with many bugs raised in it. (It's more of a review-and-polish something than a single bug), and near the end Stefan Monnier says: > "OK, let's turn things around, indeed: we revert to Stefan Bruda's indentation code, you're handed responsibility over that code, and I get to send you the bug reports about all the regressions this will introduce." It's not clear if that's meant genuinely or frustratedly and sarcastically, but it's taken genuinely and Markus Triska replies: "This would be a good improvement in most respects I consider important, thank you! I will treat all issues you and others send to me with great care and attention, and work on correcting all regressions and issues I can. I have a lot of experience editing Prolog code with Emacs and can spot regressions quickly." Followed by Stefan Monnier apparently not doing that, and fixing two (of many) issues raised and discussed. (Perhaps he considered it handed over and that the next action would be patches from Markus Triska?) Then 5 years later Lars (who wasn't involved in it?) closing the whole thing without reading it in detail, taking that as "whole thing fixed". It's not too far from Zawinski's "Cascade of Attention Deficit Teenagers" model[1] of open source bug reporting - they go unread for years, then get closed with "if it's still a problem, make a new bug". [1] https://web.archive.org/web/20210311012401/https://www.jwz.org/doc/cadt.html https://web.archive.org/web/20210311012401/https://www.jwz.o...
tw04 5y ago
> even though the issue still exists. The second to last post says they believe the issue is fixed, with nobody complaining it isn't fixed for the 5 years after. I guess that doesn't seem like a great example of "they closed the bug without ever fixing it".
mrighele 5y ago
The affected users didn't bother to check if the issue was solved for five years. I think it is fine to close it
- bombcar 5y ago
  Or they gave up checking and moved on, but the bug is still affecting others (who do not know how or don't bother to report) - some of whom may also just move on.
- ramphastidae 5y ago
  I disagree. The affected users completed their responsibility of filing a ticket, and if triage is done correctly, they should rely to the issue status or comments for updates. The alternative of having issue creators regularly ping the assignee for status updates via comments seems unproductive for both the creator and assignee.
temp8964 5y ago
The word “closed” doesn’t mean problem solved. It actually can legitimately mean the problem is ignored: we closed the case because nobody cared anymore.
- ummonk 5y ago
  That shouldn’t happen because people will continue to report the bug and open duplicate issues. Instead, it should be tagged with something like “won’t fix”.
  - jfrunyon 5y ago
    If someone reopens the bug or opens another bug, that is an indication that someone still cares.
    - meepmorp 5y ago
      WONTFIX means the developer won't fix the bug. If you still care about it, fix it yourself or pay someone to do it for you; you're not entitled to unpaid support from 3rd parties, even if you ask nicely.
      - jfrunyon 5y ago
        Please look at the context of my comment. ummonk suggested that developers should tag closed bugs with wontfix, even if they were only closed because no one cared (rather than because they don't want to fix it).
  - Joeri 5y ago
    Won’t fix can be such a trap as well because it doesn’t make the problem go away but signals to the users “we don’t care so go away”. The issue that pushed me off of android was tagged as wontfix, and doesn’t seem to be solved despite a decade of users complaining android is literally costing them money: https://issuetracker.google.com/issues/36907469?pli=1 https://issuetracker.google.com/issues/36907469?pli=1
lmilcin 5y ago
Yep. Closing issues consistently without resolving it is best way to cause your users to stop caring ever reporting new issues. If you are looking to reduce number of issues, you are on the right track, because now not only you have closed a bunch of them without putting much work into it, but less people will be bothered to document and report their issues.
distantsounds 5y ago
when your text editor has a better bug reporting feature than its text editing feature, maybe it's time you move onto something else
ricardobeat 5y ago
Assuming you're the author of that bug report, it looks like you never did reply to that last message on 23 Nov 2015, so the developer was left hanging. Seems totally fair to assume this is fixed after half a decade with zero user comments. As an observation, the whole thread is a back-and-forth exchange of a user supplying incidental test cases and the dev fixing them one by one, for months. I'm actually surprised the main emacs maintainer would put up with this - usually formatters and syntax highlighting are handled by user extensions, it's not humanly possible for one person to be an expert in 100+ programming languages and their favored styles. Someone else who is a heavy user of the language could take the time to dive in and probably fix all the formatting issues in one go. Or make a patch to bring in the third-party better-maintained prolog-mode that is mentioned in the discussion.
- deleted 5y ago
  [deleted]
- deleted 5y ago
  [deleted]
- deleted 5y ago
  [deleted]
- deleted 5y ago
  [deleted]
- triska 5y ago
  In this specific case, the Emacs maintainers took a mode which already shipped with Emacs (in fact it was the mentioned third-party Prolog mode that was already bundled with Emacs with slight modifications) and changed it so that it no longer worked as previously and also not as expected. It is definitely nice that the Emacs maintainers corrected some of these regressions which I explained in this issue with steps to reproduce them. However, the information from 23 Nov 2015 that 2 out of several regressions I had reported in this issue are now believed to be corrected does not solve the other issues I reported in the course of the discussion and which still remain. It is easy to reproduce them with the instructions I posted in case someone is still interested in correcting them. Alternatively, one can simply use the third-party mode which does not have these issues also because I had previously already contributed changes to specifically address some of these issues in that original version of the mode. The key reason for the divergence between these two versions of the same original mode is that Emacs maintainers prefer to use SMIE-based indentation for the mode, and switching the mode to SMIE in the Emacs trunk introduced the reported regressions. SMIE is an indentation and navigation engine that the Emacs maintainers provide. My impression from the discussion in the cited issue is that SMIE is lacking some of the features that are needed to implement the desired and previously supported indentation and navigation for this particular mode. There may be a way to improve SMIE to support these use cases, it may be quite hard though: I expect that if it were easy, these changes would have been made by the Emacs maintainers to solve the remaining issues too in the last few years.
userbinator 5y ago
In general, I find too much emphasis is now on "closing" an issue as soon as possible. I understand that open issues can be a burden for maintainers. That's the outcome of metrics-driven development. Getting to 0 open issues becomes the goal, and not the effect of having less buggy software. I personally despise the GitHub "auto close" bots. Some issues take a very long time to even reproduce, and the constant nagging to close really encourages a culture of "if it can't be easily fixed, it doesn't matter" --- which nicely correlates with the state of a lot of new software today: all the basic stuff works, but there are lots of obscure, almost edge-case bugs.
baby 5y ago
Your comment feels like you’ve never worked on an open source project that gets issues.
kesor 5y ago
That is how most projects on GitHub are run. There is a bot that just closes issues after periods of inactivity. As if "not fixing the bug" can be considered as inactivity. Mostly in Kubernetes repositories I keep getting this "we are closing your issue, because we cba to solve it after 4 months" notifications.
- j1elo 5y ago
  I think people set up those bots without even starting to think through the consecuences of doing so. There is nothing more hostile to users than a program that misbehaves, searching and finding that the problem was reported in 2017 and closed afterwards with the excuse of no activity for the last 6 months (or any other equally ridiculously short amount of time). Bugs won't fix themselves due to not talking about them. If you want to close a report, have a human check if the reported misbehavior does still happen, and close the bug if not (or if no way to reproduce was found). Projects seem to forget that issue reports are reports on defects of their code, so they should be the first interested in fixing whatever is wrong. I'm the kind of user who takes the time and effort to report bugs (and I'd say that already puts me on a small % of users). But when I see these "closed because of no activity", I just say "F.U., really" and go away.
  - richardfey 5y ago
    I think this is a filter that allows the issues submitted by other big companies to get the attention they deserve while at the same time maintaining the facade of operating as an open source project
- account42 5y ago
  This is how some projects on GitHub are run. Any bots like that need to be set up by the maintainers.
AussieWog93 5y ago
>However, filing issues, especially making them reproducible, can also be a burden to users, and users will stop filing issues if too many of them are closed unilaterally without actually correcting the root cause. Fantastic! Two birds with one stone!
zarkov99 5y ago
From personal experience, bug reports are cheap to generate and very expensive to investigate. Additionally often it is the case that bug that no one paid any attention to eventually does go away on its own (the environment changes, the features is removed, a single commit ends up fixing multiple symptoms of the same problem, it was actually a user error, etc). Give the morale and dev time cost of a sprawling and low fidelity bug list I sympathize with aggressive bug triage, as I had to do the same myself. The real stuff will keep popping back in, and its better to have a real but incomplete list than a complete but mostly bogus one.
- account42 5y ago
  > bug reports are cheap to generate and very expensive to investigate This is only true if you are talking about customer-service style exchanges. With bug trackers for open source projects there can be and often is quite a bit of effort put in narrowing down the bug by the reporter or other users and sometimes the fix ends up trivial and obvious to the developer after that. I agree with closing stale bugs that have had no interaction or quick way for the dev to check if the problem is fixed (after years, not weeks) - they can be reopened after all - but dismissing the effort by done by users to report bugs in the first place should not be your justification.
  - zarkov99 5y ago
    Yes, this is true, and as you say the more work is put into the bug report, the cheaper it is for the dev to investigate and the less likely it is that a bug report will be closed prematurely.
jyrkesh 5y ago
I agree with you, but also having maintained a fairly large corporate OSS project, our backlog has gotten unsustainable. We've thrown more bodies at the problem, and are trying to deputize more of the community, but I really don't know how to manage/organize super old issues that may be legitimate, but typically aren't very searchable for people with similar problems (which often aren't obviously similar).
stubish 5y ago
When you get more bug reports inbound than you can fix, you have bugs that will never be fixed. A good method of keeping your list of bugs to a manageable size is to simply declare that if a bug cannot be fixed in $timeframe, it should be closed as WONTFIX. Acknowledging that the bug or issue will remain because the projects resources have more important things do do, and it will never be dealt with unless some external factor is added (eg. a volunteer with skills prepared to prioritize the work). It also acknowledges that the longer bugs sit open, the less relevant they become. The feature they apply too may have changed beyond recognition, becomes deprecated, or the bug metastasizes and becomes a feature. It acknowledges that long open bugs are going to be reported multiple times anyway, and at least this way you get fresh, current reports rather than everyone dog piling on an ancient ticket that nobody wants to get near. You know the ones, where it has mutated over time that the initial report from 2008 bears no resemblance to what is currently being discussed, but everyone is cranky because it has been open 12 years and obviously the devs all suck... doesn't really inspire you to deal with it. So you triage your bugs into roughly the same size chunks. You measure how many of the issues you deal with per month. You prioritize the issues. If you have more issues than your monthly velocity, you close the lowest priority WONTFIX because, well, they will not be fixed. But nobody does it this way for public projects, because then they have to deal with entitled people who want their priorities to supersede your priorities, and instead you end up with an eternally growing list of bug reports that are harder and harder to maintain. And try other approaches to make it maintainable, such as making it harder to report bugs.
cycomanic 5y ago
I have to say I find it extremely bad form to write like this hear suggesting you are an unrelated party, while in fact you are the bug reporter who didn't reply when asked if the bug still persists. At least be honest about your involvement in this issue. I also dislike how your post is written to suggest that this was how the maintainer is closing many bugs, except you give one example which is your bug. This seems more like you are on some crusade because you don't like how your bug was handled.
- triska 5y ago
  You are right that I should have pointed out explicitly that I filed this specific issue. Please note though that I was not "asked if the bug still persists" before it was closed. I used this specific example to illustrate the general point I was making, and I took an issue I filed myself because I know for certain that it still persists. You will find other issues in the Emacs bug tracker (such as https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45577 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45577) that follow the same general pattern, but where in contrast it is somewhat unclear if the issue is now solved or not, and therefore I did not cite such an issue. Another example, an issue which I also filed and which was closed even though the issue still persists: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35005 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35005 It is true: I do not like how these issues were handled, especially that they are closed without actually solving them. The Emacs bug tracker is also not like the one on Github, you have to control it with dedicated email messages. In fact, I would have to look up how to even "reopen" an Emacs bug, it is not very clear to users, and this makes it especially frustrating if issues are closed without solution. My impression from several years of filing Emacs issues is that issues are currently closed prematurely more often than was previously the case. Maybe this impression is amplified by the fact that Emacs has not even had a dedicated bug tracker for a long time, so issues were never really "closed", but the discussion simply petered out.
  - githubalphapapa 5y ago
    > In fact, I would have to look up how to even "reopen" an Emacs bug, it is not very clear to users, and this makes it especially frustrating if issues are closed without solution. At the top of your bug report, it says: To add a comment to this bug, you must first unarchive it, by sending a message to control AT debbugs.gnu.org, with unarchive 21526 in the body. You can then email your comments to 21526 AT debbugs.gnu.org in the normal way.

by triska 5y ago

tpmx 5y ago

146 messages in that bug thread. Wow.

irrational 5y ago
> I'm going to go ahead and guess that the problems discussed were fixed, and I'm closing this bug report. If only there was a way to find out, instead of guessing. I’m going to start trying this at work. I wonder how it will be received?
- jerrysievert 5y ago
  I’m going to guess that when you close issues that are years old, a fraction of them will reappear as enough people have devised workarounds for the issues and they will become the de facto fix.
- namdnay 5y ago
  > I’m going to start trying this at work. I wonder how it will be received? You’ve never done that at work? In every company I’ve worked for, nobody would bat an eyelid at dropping an issue that hasn’t been touched for more than a year
  - nsizx 5y ago
    That's how we got that stupid bot on GitHub that constantly says "comment here or I'll close this". From time to time I have to waste my time that way. I wonder if this means maintainers want us all day bumping bugs?
    - arthur2e5 5y ago
      I have this “ready with tests” PR for almost a year now, and every time I get a notification it’s either the bot or someone who really wants the PR to be merged bumping it up for me. I don’t even care so much about it any more…
  - deleted 5y ago
    [deleted]
  - irrational 5y ago
    Without testing to see if it is actually fixed? Never. Though, to be honest, it is QA who is testing it, not us developers. But, only QA can close a ticket and no way would they close it without being 100% sure it is fixed.
    - phkahler 5y ago
      For QA to test tell if it's fixed, they must have a test case. If there is a test case here, the devs wouldn't have to guess?
      - joshuaissac 5y ago
        The bug reproduction steps (along with expected vs actual behaviour) are in the opening comment of the bug report, so they really should not have had to guess.
      - irrational 5y ago
        See my response to kortilla above.
    - 5y ago
- taeric 5y ago
  Yeah... This actually seems standard for old backlogs. Were all problems fixed? Almost certainly not. Many will have become overcome by events, though. The ones that are still pertinent will reopen. Such that anytime I see a large percentage of bugs closed like this, this reflects more on working in the ticketing system than it does on fixing the problem it is managing.
- toast0 5y ago
  When I worked for Facebook, the had a bugtracker bot that closes open issues after 6? months of no activity. It's sort of nice, but also terrible.
- aprdm 5y ago
  I’ve done this at work many times, it’s the only way I’ve found to keep a big project back log under control… if people care enough they can reopen
- thrower123 5y ago
  Everybody does this, it's the normal behavior with enterprise bugs. They report something. You badger them for six weeks to collect enough information to reproduce it. You fix the problem and slate it into a release and make it available. They don't take the release for another seven months.

6AA4FD 5y ago

This has always been my problem with emacs. The basic interpreter and interface design is phenomenal, but it is so bogged down and buggy it is frustrating to actually push it to the limits of capability. I wish the devs would just drop support for stuff that can be maintained just as well as a plugin.

yjftsjthsd-h 5y ago
Time for a neomacs?

agumonkey 5y ago

It's super sad considering the new stream of users of all levels, but energy is spent at the higher layers (emacs config, org tricks) rather than core..

6AA4FD 5y ago
This is probably because it is relatively easy to add more elisp flourishes, another seven major modes for editing JavaScript, much harder to actually improve the core.
- shadowgovt 5y ago
  As with any large system, improvements to core also risk compromising large, popular packages.
- agumonkey 5y ago
  I wonder how remacs guys are doing now
  - the-smug-one 5y ago
    They're no longer taking PRs, development has moved over to emacs-ng with a different perspective on how to improve Emacs.
fanf2 5y ago
There's a new elisp JIT in emacs 28 https://emacsconf.org/2020/talks/38/ https://emacsconf.org/2020/talks/38/ There's a new portable undump in emacs 27 https://www.masteringemacs.org/article/whats-new-in-emacs-27-1 https://www.masteringemacs.org/article/whats-new-in-emacs-27... a couple of examples of very core features off the top of my head
- agumonkey 5y ago
  I had no idea about the new JIT but in any case it would be nice if more manpower was allocated on fixing bugs I guess.

mhils 5y ago

Last message in the thread: > I'm going to go ahead and guess that the problems discussed were fixed, and I'm closing this bug report. If there's anything more to be worked on here, please send a mail to the debbugs address and we'll reopen the bug report. I don't think this really qualifies as "ignoring". Having read the last two messages or so, their approach looks totally reasonable to me. Please don't scold maintainers for cleaning up? :(

thrdbndndn 5y ago
I'm kind of on the fence for these (in general, not specific to this ticket). Assuming the STR is clear, is it the original reporter's responsibility, or the developer's, to confirm if a bug is fixed or not?
- xdfgh1112 5y ago
  No other approach is sustainable.
  - jfrunyon 5y ago
    Really? You think that expecting a user who submitted a bug report five years earlier to still have patience to interact with it is sustainable?
    - ReverseCold 5y ago
      Maybe if the bug is important, someone else will reply to confirm? That could be a reasonable line of thinking.
      - Chilinot 5y ago
        Yea, if a bug has been open without further discussion for 5 years then i would too take for granted that the issue is no longer an issue and close it.
      - mpweiher 5y ago

lixtra 5y ago

The last message 6 years ago reads that the dev thinks the bug is fixed. Since then no-one complained. Do you know that the bug was falsely closed? Isn’t it more an example of a bug submitter loosing interest in their bug? Disclaimer: I did not read all 146 messages.

jodrellblank 5y ago
The person you are replying to here (triska) is the original bug opener Markus Triska. A skim read of the thread, there's a long back-and-forth of Prolog parsing and formatting and interaction with Emacs movements, with many bugs raised in it. (It's more of a review-and-polish something than a single bug), and near the end Stefan Monnier says: > "OK, let's turn things around, indeed: we revert to Stefan Bruda's indentation code, you're handed responsibility over that code, and I get to send you the bug reports about all the regressions this will introduce." It's not clear if that's meant genuinely or frustratedly and sarcastically, but it's taken genuinely and Markus Triska replies: "This would be a good improvement in most respects I consider important, thank you! I will treat all issues you and others send to me with great care and attention, and work on correcting all regressions and issues I can. I have a lot of experience editing Prolog code with Emacs and can spot regressions quickly." Followed by Stefan Monnier apparently not doing that, and fixing two (of many) issues raised and discussed. (Perhaps he considered it handed over and that the next action would be patches from Markus Triska?) Then 5 years later Lars (who wasn't involved in it?) closing the whole thing without reading it in detail, taking that as "whole thing fixed". It's not too far from Zawinski's "Cascade of Attention Deficit Teenagers" model[1] of open source bug reporting - they go unread for years, then get closed with "if it's still a problem, make a new bug". [1] https://web.archive.org/web/20210311012401/https://www.jwz.org/doc/cadt.html https://web.archive.org/web/20210311012401/https://www.jwz.o...

tw04 5y ago

> even though the issue still exists. The second to last post says they believe the issue is fixed, with nobody complaining it isn't fixed for the 5 years after. I guess that doesn't seem like a great example of "they closed the bug without ever fixing it".

mrighele 5y ago

The affected users didn't bother to check if the issue was solved for five years. I think it is fine to close it

bombcar 5y ago
Or they gave up checking and moved on, but the bug is still affecting others (who do not know how or don't bother to report) - some of whom may also just move on.
ramphastidae 5y ago
I disagree. The affected users completed their responsibility of filing a ticket, and if triage is done correctly, they should rely to the issue status or comments for updates. The alternative of having issue creators regularly ping the assignee for status updates via comments seems unproductive for both the creator and assignee.

temp8964 5y ago

The word “closed” doesn’t mean problem solved. It actually can legitimately mean the problem is ignored: we closed the case because nobody cared anymore.

ummonk 5y ago
That shouldn’t happen because people will continue to report the bug and open duplicate issues. Instead, it should be tagged with something like “won’t fix”.
- jfrunyon 5y ago
  If someone reopens the bug or opens another bug, that is an indication that someone still cares.
  - meepmorp 5y ago
    WONTFIX means the developer won't fix the bug. If you still care about it, fix it yourself or pay someone to do it for you; you're not entitled to unpaid support from 3rd parties, even if you ask nicely.
    - jfrunyon 5y ago
      Please look at the context of my comment. ummonk suggested that developers should tag closed bugs with wontfix, even if they were only closed because no one cared (rather than because they don't want to fix it).
- Joeri 5y ago
  Won’t fix can be such a trap as well because it doesn’t make the problem go away but signals to the users “we don’t care so go away”. The issue that pushed me off of android was tagged as wontfix, and doesn’t seem to be solved despite a decade of users complaining android is literally costing them money: https://issuetracker.google.com/issues/36907469?pli=1 https://issuetracker.google.com/issues/36907469?pli=1

lmilcin 5y ago

Yep. Closing issues consistently without resolving it is best way to cause your users to stop caring ever reporting new issues. If you are looking to reduce number of issues, you are on the right track, because now not only you have closed a bunch of them without putting much work into it, but less people will be bothered to document and report their issues.

distantsounds 5y ago

when your text editor has a better bug reporting feature than its text editing feature, maybe it's time you move onto something else

ricardobeat 5y ago

Assuming you're the author of that bug report, it looks like you never did reply to that last message on 23 Nov 2015, so the developer was left hanging. Seems totally fair to assume this is fixed after half a decade with zero user comments. As an observation, the whole thread is a back-and-forth exchange of a user supplying incidental test cases and the dev fixing them one by one, for months. I'm actually surprised the main emacs maintainer would put up with this - usually formatters and syntax highlighting are handled by user extensions, it's not humanly possible for one person to be an expert in 100+ programming languages and their favored styles. Someone else who is a heavy user of the language could take the time to dive in and probably fix all the formatting issues in one go. Or make a patch to bring in the third-party better-maintained prolog-mode that is mentioned in the discussion.

deleted 5y ago
[deleted]
deleted 5y ago
[deleted]
deleted 5y ago
[deleted]
deleted 5y ago
[deleted]
triska 5y ago
In this specific case, the Emacs maintainers took a mode which already shipped with Emacs (in fact it was the mentioned third-party Prolog mode that was already bundled with Emacs with slight modifications) and changed it so that it no longer worked as previously and also not as expected. It is definitely nice that the Emacs maintainers corrected some of these regressions which I explained in this issue with steps to reproduce them. However, the information from 23 Nov 2015 that 2 out of several regressions I had reported in this issue are now believed to be corrected does not solve the other issues I reported in the course of the discussion and which still remain. It is easy to reproduce them with the instructions I posted in case someone is still interested in correcting them. Alternatively, one can simply use the third-party mode which does not have these issues also because I had previously already contributed changes to specifically address some of these issues in that original version of the mode. The key reason for the divergence between these two versions of the same original mode is that Emacs maintainers prefer to use SMIE-based indentation for the mode, and switching the mode to SMIE in the Emacs trunk introduced the reported regressions. SMIE is an indentation and navigation engine that the Emacs maintainers provide. My impression from the discussion in the cited issue is that SMIE is lacking some of the features that are needed to implement the desired and previously supported indentation and navigation for this particular mode. There may be a way to improve SMIE to support these use cases, it may be quite hard though: I expect that if it were easy, these changes would have been made by the Emacs maintainers to solve the remaining issues too in the last few years.

userbinator 5y ago

In general, I find too much emphasis is now on "closing" an issue as soon as possible. I understand that open issues can be a burden for maintainers. That's the outcome of metrics-driven development. Getting to 0 open issues becomes the goal, and not the effect of having less buggy software. I personally despise the GitHub "auto close" bots. Some issues take a very long time to even reproduce, and the constant nagging to close really encourages a culture of "if it can't be easily fixed, it doesn't matter" --- which nicely correlates with the state of a lot of new software today: all the basic stuff works, but there are lots of obscure, almost edge-case bugs.

baby 5y ago

Your comment feels like you’ve never worked on an open source project that gets issues.

kesor 5y ago

That is how most projects on GitHub are run. There is a bot that just closes issues after periods of inactivity. As if "not fixing the bug" can be considered as inactivity. Mostly in Kubernetes repositories I keep getting this "we are closing your issue, because we cba to solve it after 4 months" notifications.

j1elo 5y ago
I think people set up those bots without even starting to think through the consecuences of doing so. There is nothing more hostile to users than a program that misbehaves, searching and finding that the problem was reported in 2017 and closed afterwards with the excuse of no activity for the last 6 months (or any other equally ridiculously short amount of time). Bugs won't fix themselves due to not talking about them. If you want to close a report, have a human check if the reported misbehavior does still happen, and close the bug if not (or if no way to reproduce was found). Projects seem to forget that issue reports are reports on defects of their code, so they should be the first interested in fixing whatever is wrong. I'm the kind of user who takes the time and effort to report bugs (and I'd say that already puts me on a small % of users). But when I see these "closed because of no activity", I just say "F.U., really" and go away.
- richardfey 5y ago
  I think this is a filter that allows the issues submitted by other big companies to get the attention they deserve while at the same time maintaining the facade of operating as an open source project
account42 5y ago
This is how some projects on GitHub are run. Any bots like that need to be set up by the maintainers.

AussieWog93 5y ago

>However, filing issues, especially making them reproducible, can also be a burden to users, and users will stop filing issues if too many of them are closed unilaterally without actually correcting the root cause. Fantastic! Two birds with one stone!

zarkov99 5y ago

From personal experience, bug reports are cheap to generate and very expensive to investigate. Additionally often it is the case that bug that no one paid any attention to eventually does go away on its own (the environment changes, the features is removed, a single commit ends up fixing multiple symptoms of the same problem, it was actually a user error, etc). Give the morale and dev time cost of a sprawling and low fidelity bug list I sympathize with aggressive bug triage, as I had to do the same myself. The real stuff will keep popping back in, and its better to have a real but incomplete list than a complete but mostly bogus one.

account42 5y ago
> bug reports are cheap to generate and very expensive to investigate This is only true if you are talking about customer-service style exchanges. With bug trackers for open source projects there can be and often is quite a bit of effort put in narrowing down the bug by the reporter or other users and sometimes the fix ends up trivial and obvious to the developer after that. I agree with closing stale bugs that have had no interaction or quick way for the dev to check if the problem is fixed (after years, not weeks) - they can be reopened after all - but dismissing the effort by done by users to report bugs in the first place should not be your justification.
- zarkov99 5y ago
  Yes, this is true, and as you say the more work is put into the bug report, the cheaper it is for the dev to investigate and the less likely it is that a bug report will be closed prematurely.

jyrkesh 5y ago

I agree with you, but also having maintained a fairly large corporate OSS project, our backlog has gotten unsustainable. We've thrown more bodies at the problem, and are trying to deputize more of the community, but I really don't know how to manage/organize super old issues that may be legitimate, but typically aren't very searchable for people with similar problems (which often aren't obviously similar).

stubish 5y ago

When you get more bug reports inbound than you can fix, you have bugs that will never be fixed. A good method of keeping your list of bugs to a manageable size is to simply declare that if a bug cannot be fixed in $timeframe, it should be closed as WONTFIX. Acknowledging that the bug or issue will remain because the projects resources have more important things do do, and it will never be dealt with unless some external factor is added (eg. a volunteer with skills prepared to prioritize the work). It also acknowledges that the longer bugs sit open, the less relevant they become. The feature they apply too may have changed beyond recognition, becomes deprecated, or the bug metastasizes and becomes a feature. It acknowledges that long open bugs are going to be reported multiple times anyway, and at least this way you get fresh, current reports rather than everyone dog piling on an ancient ticket that nobody wants to get near. You know the ones, where it has mutated over time that the initial report from 2008 bears no resemblance to what is currently being discussed, but everyone is cranky because it has been open 12 years and obviously the devs all suck... doesn't really inspire you to deal with it. So you triage your bugs into roughly the same size chunks. You measure how many of the issues you deal with per month. You prioritize the issues. If you have more issues than your monthly velocity, you close the lowest priority WONTFIX because, well, they will not be fixed. But nobody does it this way for public projects, because then they have to deal with entitled people who want their priorities to supersede your priorities, and instead you end up with an eternally growing list of bug reports that are harder and harder to maintain. And try other approaches to make it maintainable, such as making it harder to report bugs.

cycomanic 5y ago

I have to say I find it extremely bad form to write like this hear suggesting you are an unrelated party, while in fact you are the bug reporter who didn't reply when asked if the bug still persists. At least be honest about your involvement in this issue. I also dislike how your post is written to suggest that this was how the maintainer is closing many bugs, except you give one example which is your bug. This seems more like you are on some crusade because you don't like how your bug was handled.

triska 5y ago
You are right that I should have pointed out explicitly that I filed this specific issue. Please note though that I was not "asked if the bug still persists" before it was closed. I used this specific example to illustrate the general point I was making, and I took an issue I filed myself because I know for certain that it still persists. You will find other issues in the Emacs bug tracker (such as https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45577 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45577) that follow the same general pattern, but where in contrast it is somewhat unclear if the issue is now solved or not, and therefore I did not cite such an issue. Another example, an issue which I also filed and which was closed even though the issue still persists: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35005 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35005 It is true: I do not like how these issues were handled, especially that they are closed without actually solving them. The Emacs bug tracker is also not like the one on Github, you have to control it with dedicated email messages. In fact, I would have to look up how to even "reopen" an Emacs bug, it is not very clear to users, and this makes it especially frustrating if issues are closed without solution. My impression from several years of filing Emacs issues is that issues are currently closed prematurely more often than was previously the case. Maybe this impression is amplified by the fact that Emacs has not even had a dedicated bug tracker for a long time, so issues were never really "closed", but the discussion simply petered out.
- githubalphapapa 5y ago
  > In fact, I would have to look up how to even "reopen" an Emacs bug, it is not very clear to users, and this makes it especially frustrating if issues are closed without solution. At the top of your bug report, it says: To add a comment to this bug, you must first unarchive it, by sending a message to control AT debbugs.gnu.org, with unarchive 21526 in the body. You can then email your comments to 21526 AT debbugs.gnu.org in the normal way.