[HN Gopher] Closing 45% of the open Emacs bugs
___________________________________________________________________
Closing 45% of the open Emacs bugs
Author : clircle
Score : 239 points
Date : 2021-08-14 15:48 UTC (7 hours ago)
(HTM) web link (lars.ingebrigtsen.no)
(TXT) w3m dump (lars.ingebrigtsen.no)
| siraben wrote:
| > Just a reminder: Working on the development version of Emacs is
| easy on most operating systems.
|
| With Nix, it's amazing to be able to just run (on macOS/Linux)
| nix develop nixpkgs#emacs
|
| and be on my way to fetch the tarball and compile (dependencies
| already loaded into PATH). The same goes for packages like vim or
| even firefox, if you wanted to hack on them.
| gvd wrote:
| They shut down emacs?
| CyberRabbi wrote:
| I'm disturbed that he needed a for loop to compute 100*(1-0.9^10)
| codesections wrote:
| > I'm disturbed that he needed a for loop to compute
| 100*(1-0.9^10)
|
| I assumed that he just wanted a reason to include at least a
| _little_ elisp. (Though, even so, he could at least have run
| the calculation recursively; in Raku, I'd probably have written
| (-> $_, $i { $i ?? &?BLOCK($_ x .9, $i-1) !! $_ })(100, 10)
|
| if I wanted an alternative to `100 x (1 - .910)`
| kzrdude wrote:
| What's the most exciting features recently added to Emacs (or
| coming soon)? I don't use emacs at all, so any feature you're
| excited for is fair game, even if it's not exactly recent.
| dotancohen wrote:
| I'm not an Emacs user per se, but I am an org-mode user. I
| don't even know where to begin to start recommending org-mode,
| it is a literal life changer. It is everything that you've ever
| wanted in any note-taking app (Except perhaps syncing with
| mobile devices, but people are working on that).
|
| Seriously, go through the fine tutorial and just start
| exploring it. No matter what you put off for doing that, it
| will be worth it.
|
| https://orgmode.org/worg/org-tutorials/orgtutorial_dto.html
| TacticalCoder wrote:
| native-comp
|
| LSP support (Language Server Protocol). Basically any language
| / file format for which a LSP backend has been written can now
| be used from Emacs.
|
| LSP is not as powerful yet as, say, IntelliJ IDEA for Java
| development but suddenly the line between "text editor" and
| "IDE" for Emacs got much, much, much more blurry.
| jhgb wrote:
| > but suddenly the line between "text editor" and "IDE" for
| Emacs got much, much, much more blurry
|
| SLIME already did this to Emacs like twenty years ago.
| jonpalmisc wrote:
| Somewhat recently the native-comp branch was merged which
| compiles Elisp to native code.
|
| In my experience, this has a huge positive impact on
| performance, and can make Emacs feel a lot faster, smoother,
| and more responsive. Others say it doesn't yield a noticeable
| difference for them, but on both of my machines it's quite
| noticeable.
| TroisM wrote:
| I changed my Google password, and overall, I received 6 security
| alerts because of it... I wish that Google would close some bugs
| too. They are also known for closing unfixed bugs though...
| H8crilA wrote:
| If you work for a corporation and feel overwhelmed try what the
| emacs people did, example for email: 1) select everything in your
| inbox, 2) mark as read, 3) archive. For bugs it would be unassign
| everything from yourself, or just close them without fixing.
|
| I've done this several times and it's magical how you end up
| losing almost nothing important in the end. I think it works
| because if something is important enough you'll either remember
| it yourself or it will be communicated to you again, perhaps even
| via a "higher priority channel" such as the management chain.
|
| And if you think I'm being extreme then yes, maybe, but maybe you
| haven't yet drowned in the never ending stream of problems for a
| long time.
| aprdm wrote:
| When I was young I hated that my manager asked me to email many
| times if it was important.
|
| Nowadays I understand ... it's the a way to keep sane and to
| see what matters. Mainly in companies that have been around for
| decades with multiple products and many many people..
| ploxiln wrote:
| I've been in a place where lots of things were flaky and sub-
| optimal, and leadership could not prioritize, because only P0
| CRITICAL was ever actually addressed, lots of dumb stuff had
| to be marked P0 CRITICAL to have any chance of consideration,
| and lots of little easy bugs reported from reasonable
| developers were never fixed.
|
| So, this doesn't always work, it can just be a way to kick
| the can around, and end up in the same place but with lots of
| extra junk flying by.
| waych wrote:
| When doing this email trick I'd often broadcast the fact as I
| was "declaring email bankruptcy" to let others know I did this
| and may have missed their email.
|
| I've also lead many mass bug closures. Most stale bugs just
| need a ping or a friendly closure message. The cost to reverse
| a wrongly closed bug from a bug cleanup sweep is zero, and in
| the off chance it ignites interest in some other party still
| paying attention it at least signals intent and starts a
| conversation.
| colechristensen wrote:
| This is definitely a real phenomenon, there is a lot of "work"
| that if ignored long enough turns out didn't need to be done at
| all. Lots of things get done which don't need to, knowing which
| is which is a really valuable skill.
| throwawayboise wrote:
| At my job I have learned which people ask for things that
| they aren't really serious about. Only so many times I am
| willing to reorganize my work to install some "urgently"
| needed software or system configuration changes, only to
| later observe that they were never used.
|
| Now when I get requests from those people, they go
| immediately to the back burner. If I hear nothing more, they
| get closed; if I get followups then maybe it is something
| they need after all.
|
| It's easy for people to ask for others to do things. But many
| people are scatterbrained and can't prioritize, and can't see
| beyond their own immediate needs and how their requests might
| impact other work. Rather than try to demand some realistic
| sense of priority for these requests, this approach lets the
| urgent stuff bubble up naturally and the rest of the chaff
| sink to the bottom.
| doctor_eval wrote:
| I almost agreed with you until you used the pejorative
| "scatterbrained". I think the explanation is "asymmetry".
|
| It's simply easier to make a request, than it is to resolve
| it. The cost of filing an issue is greater than the cost of
| resolving it.
|
| This is why schemes like "you can only file your top 3
| issues" make sense. Forcing the end user to prioritise
| their top issues - and to manage the ones that don't make
| the cut - distributes the triage work more fairly.
|
| We have a job to do too and it's a waste of developers time
| to force us to guess what's important to an end user.
| That's their job.
| TeMPOraL wrote:
| > _It 's easy for people to ask for others to do things.
| But many people are scatterbrained and can't prioritize,
| and can't see beyond their own immediate needs and how
| their requests might impact other work._
|
| But, should they even care? Maybe they think it's not their
| job?
|
| What I mean is, there seem to be two archetypes of ways to
| ask someone else for something. For lack of better terms,
| I'll call them "market approach" and "social approach".
|
| "Social approach" is when you try to predict how costly
| your request will be to the other person, and only ask them
| if the importance is clearly much greater than the cost.
| You then expect the other person to feel compelled to
| prioritize your request, as they know you wouldn't be
| asking if it wasn't very important.
|
| "Market approach" is when you don't give any thought about
| the cost to other party - you just make your request, and
| expect _them_ to tell you whether they 'll do it, how long
| will it take, and what they expect in return. You then
| negotiate the scope of the request and the "price" until
| both sides are satisfied, or the request is rejected.
|
| I don't know which one is better. But I think we're living
| the worst case: everyone operates at a different point
| between these two idealized approaches. So, in your
| example, you're taking the "social" perspective - you treat
| requests as high priority ("they wouldn't have asked if it
| wasn't important") and get annoyed when your hard work
| isn't used. Meanwhile, those people may be operating closer
| to the "market" perspective - perhaps they expected _you_
| to push back on their request if it 's disruptive to you,
| and were willing to negotiate (they knew it wasn't that
| important, but they didn't expect you to assume it was).
| doctor_eval wrote:
| I like this comment too but in many cases the requesting
| party has almost no relationship to the receiving party.
| The requester is almost always in a buyers market (filing
| an issue is cheap) and the receiver is almost always
| social (working closely with others to resolve issues).
|
| This model does explain the different sides, but the
| problem remains.
|
| So it seems that the problem with the requester's market
| approach is that there is no mechanism for setting value.
| So how do we solve that?
| j1elo wrote:
| I agree with the sibling comment, your comment transmits
| a great insight that would make for a great longer form
| read. Deep down, this is another instance of the problem
| of human expectations and how important it is to handle
| them correctly for sane interactions with other peers at
| work.
| dmurray wrote:
| This is a great insight and deserves to be turned into a
| more pretentious blog post that goes viral on VC Twitter.
|
| I should get better at recognizing which of my partners
| are on the social strategy and who prefers a more market-
| based one. Probably all of us should learn this skill.
| rightbyte wrote:
| There are crappy workarounds for many bugs. The cost is just
| moved from the mantainer to the user. After a while the bug
| becomes lore.
| seoaeu wrote:
| Sometimes it is more a matter of getting most of the work
| done, without it mattering if some gets missed. Ignoring all
| reported bugs might be unsustainable because eventually all
| your customers would get fed up and leave, but it is unlikely
| that any particular bug would be the breaking point between
| the company succeeding or going under.
| asah wrote:
| +1 - subtly, if it's important someone will re-file or re-open
| it.
| xoa wrote:
| > _+1 - subtly, if it 's important someone will re-file or
| re-open it._
|
| With all due respect, this absolutely is not the only
| outcome. I'm going through this right now with UniFi and
| Ubiquiti, which has been a raging development dumpster fire
| for years now though the rot has only really started to
| become critical and more generally obvious the last year or
| two. UniFi is full of very important bugs, issues, and
| missing or badly implemented core functionality. But, like
| many many others, after devoting a lot of time to detailed
| bug reports and figuring out how to make it reproducible and
| extensive work helping identify how to meet standards that
| all got closed/ignored or even actively got worse?
|
| I simply don't give a flying fuck any longer. I'm not "re-
| filing" (of course, they've dumped even their minimal
| mediocre old feature/bug tracker anyway with no replacement,
| but I don't make new threads either). I mostly don't bother
| anymore with reporting anything UniFi at all. Instead I've
| been steadily migrating away entirely. For me, UniFi is now
| in a completely subservient role, still doing a certain
| amount of switching and WiFi but with 100% of core network
| functions, routing/gateway coverage etc moved to OPNsense. As
| the time comes to get new gear anyway for WiFi 6E/7 and more
| multigig switching that'll be the end of it for my ~100
| pieces of kit.
|
| Of course companies/projects are free not to care, and
| depending on what sort of goal a project has or what sort of
| lock-in/stickiness and core revenue areas a business has it
| may indeed not matter if there is an exodus of small/older
| users/customers. But it shouldn't be assumed in every
| instance that "if this is really important someone will poke
| us again" because everyone only has so much time themselves
| to poke you, and if word gets around that it's pointless to
| even try than that will be the last you hear from them until
| they're gone entirely. IMO, the true terror for many
| business/projects shouldn't be criticism, it's _silence_.
| When people simply don 't even care enough to even invest the
| time to get mad anymore.
| touisteur wrote:
| Yeah and I agree especially for poorly documented issues,
| unclear demands on your time, etc.
|
| But as someone with a long QA experience, sometimes I'm so
| disappointed in the 'no one bothered me, it must be bothering
| no one, close'. What about the time and effort of the person
| who described a defect in your system? Don't you want people
| giving you clear, researched bug reports? When you close
| their issues, although there CLEARLY is a problem and the
| ball is CLEARLY in your (sw dev) team, I feel like you're
| saying 'don't give me precise, actionable bugs'. That's what
| I'm hearing anyway.
|
| And soon enough you get the eternal dev complaint about how
| 'no one fills tickets properly' and the 'no one opens issues
| anymore although they face clear annoying bugs' with heavy
| faulpelz connotations... Well you reap what you sow.
|
| I'm not saying the project has infinite resources and that
| you should fix all issues all the time... I actually
| understand the real world tradeoffs. But put them on a
| special list, like knowledge database, known-bugs, not
| 'closed until some annoying piece-of-work busybody
| complains', and try earnestly to fix one once in a while, I
| even had a principle when I was team lead, to correct at
| least 5 more-than-2-years-old issues (or add a 'red' test for
| that bug). After all with tech turnover, those often make
| great onramping tickets.
|
| And I can testify to the sheer joy of having one of your 'low
| priority' issues fixed, even 2-3 years later. 'hey I know
| it's been a long time, and we're not sure it's still annoying
| to you, but anyway we managed to reproduce on the latest
| version and we put a fix in place, let us know if you want a
| nightly to double-check or wait until next release'. Even
| though it doesn't show on SLAs, I do put in a word when
| renewal time comes around (even more now that I have a small
| bit of clout).
| touisteur wrote:
| And the worst part is that for anything else than clearly
| laid out bugs/issues, I apply GP's described strategy (if
| it is important, it'll come back or I'll remember),
| especially as a protection against burnout. I have taught
| myself to stop worrying missing an email or not be on top
| of everyfuckingthing. Yeah I'll come around to look and
| will say 'must be redone, sorry' and there's waste. It's
| bad. But you can't do everything and when the external
| environment doesnt you adjust to your work capacity by
| itself, I've decided to let not-so-critical things slide a
| bit. If/when there's a complaint, either I'll resend the
| email about not having the time to follow subject X or my
| manager will... It's OK.
| wiz21c wrote:
| FTA : "I think you can pretty much pinpoint the date I didn't
| have to work any more after the startup I was a co-owner of was
| bought and found myself with a lot of free time on my hands?
| Kinda? So I've been basically working full time on Emacs bug
| fixing (and triage) for a couple years (with some holidays at
| random) instead."
|
| I would love to be in such a situation... Unfortunately, I don't
| have a start up to sell so I'll be a slave all my life and won't
| have the opportunity to work full time for a non profit project
| that I love. Dies irae.
| tasuki wrote:
| Not having a startup to sell doesn't mean you have to be a
| slave all your life. You could find a job you enjoy, or save up
| some money and retire. Look up "financial independence/retiring
| early" - it's not suitable for everyone, but if you're here,
| you probably qualify :)
| alexyz12 wrote:
| Im curious to hear more about his startup. I can't find it
| online yet...
| chr wrote:
| Netfonds offered online stock trading in Norway. Now sold to
| their competitor Nordnet.
| rStar wrote:
| thanks so much
| throwawayboise wrote:
| I don't really know how the emacs project is organized but I
| would have assumed that prolog-mode was maintained on its own by
| prolog-emacs enthusiasts, and not the core emacs project. I am
| hard pressed to consider a complaint about indenting in a
| specific language mode an "Emacs bug"
| db48x wrote:
| The only real requirements for getting something included with
| Emacs itself are that you assign copyright to the FSF and that
| the code basically works.
|
| There are well over a million lines of Emacs Lisp code included
| with Emacs (a million and a half, last time I checked), and
| most of that is for things that the average user won't need
| right away, or won't ever need. The goal is to make Emacs (and
| by extension Free Software) comprehensive, not to limit the
| amount of work that the maintainers might need to do. The work
| they do is naturally limited by the amount of time that they
| have in a day, so of course it falls to the rest of us to chip
| in from time to time, especially with language-specific modes
| where the maintainers may not use that specific language
| themselves.
| jph wrote:
| "I'm going to go ahead and guess that the problems discussed were
| fixed, and I'm closing this bug report. "
|
| This is not a way to assert a bug is fixed. Success looks like
| actually trying the code in the bug report that demonstrates the
| bug, and/or contacting the report participants, to confirm that
| the bug is actually fixed for the participants.
| convolvatron wrote:
| cleaning up the bug reporting system is often one of my jobs.
|
| the point of a bug report is to let you know something is going
| on, to provide context useful in tracking it down, and tracking
| for the eventual resolution.
|
| as they years tick by, some bug reports are counterproductive
| because they are unclear, dont give _any_ diagnostic
| information, or are no longer relevant because the codebase has
| shifted.
|
| its great to say for each of these issues we should spend a day
| or two trying to reproduce them - but its really not the best
| use of time.
|
| we're not talking about capriciously trashing useful bug
| reports. we're trying to lower the noise floor so that the
| actionable bugs stand out and are more likely to be dealt with.
| woko wrote:
| The same way we have text classification for the spam in our
| mail inbox, couldn't someone train a model to classify issues
| as actionable bugs vs. noise for large projects like the one
| mentioned in the OP? Data would come from closed issues:
|
| - if the issue lead to a commit, or a merge is mentioned in
| the thread, then it is actionable,
|
| - if the issue was closed without any code change, then it is
| noise.
| 542458 wrote:
| You do see a decent number of GitHub bots that will trash
| issues if they don't comply to some sort of
| "expected/observed/steps/specs" format, which I think more
| or less accomplishes the same thing. The only issue is
| you're potentially losing out on issues from less-tech-
| savvy users, but I guess simply using GitHub filters many
| of those people anyways.
| convolvatron wrote:
| maybe. but i think this process really helps develop a
| deeper understanding of the evolution of the project and
| doesn't take that much time.
|
| and I bet your AI isn't going to be able to say 'oh yeah,
| thats just that thing we fixed in 2.1'
|
| seems useful in a second-order capacity though - process
| introspection
| chrsig wrote:
| It had been believed to have been fixed over 5 years ago, and
| had no follow up from the reporter to confirm or refute. Why
| should a maintainer spend more time on it at this point?
| UglyToad wrote:
| I'm reacting from a place of emotion here but your suggested
| approach just doesn't scale for an open-source project. Nothing
| is more soul-destroying than an ever growing backlog. If people
| don't care enough to follow up with an easy reproducible case
| or even open the PR to fix themselves then they have no right
| to squat the backlog.
|
| Sure for commercial situations you expect the customer to sign
| off on a fix but a maintainer's responsibility in open source
| is exactly 0. Even having a bug tracker is an affordance from
| the maintainer, GitHub supports turning issues off.
|
| I'm going to continue to terminate old issues where the problem
| described was vague or the reporter has gone AWOL and I would
| encourage all OSS maintainers out there to do the same, let's
| manage expectations.
| fragbait65 wrote:
| My company that I work at actually closes bug reports that has
| been in "pending customer feedback" for more than 6 months
| automatically. The customer is free to re-open the issue at a
| later date if it's still an issue.
|
| I personally think that's fine. You'd have the time to verify
| and close every issue in a perfect world, but the world rarely
| is. Before that we had 100+ issues open with bugs we could not
| even reproduce that where open for years. It just becomes
| clutter at that point.
| mook wrote:
| That seems reasonable, because you're waiting for a response
| that may not arrive. This is very different from a bug where
| all necessary customer feedback had already been collected,
| and is pending a fix.
| triska wrote:
| 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
|
| 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 wrote:
| 146 messages in that bug thread. Wow.
| irrational wrote:
| > 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?
| toast0 wrote:
| 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.
| jerrysievert wrote:
| 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.
| thrower123 wrote:
| 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.
| namdnay wrote:
| > 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 wrote:
| 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 wrote:
| 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]
| irrational wrote:
| 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 wrote:
| 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?
| irrational wrote:
| See my response to kortilla above.
| joshuaissac wrote:
| 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.
| Chilinot wrote:
| QA is not your test suite. Test your own code, submit
| working code, let QA try to break it.
|
| Dont just push code and expect others to point out your
| flaws. Take some responsibility.
| irrational wrote:
| See my response to kortilla above.
| kortilla wrote:
| > Though, to be honest, it is QA who is testing it, not
| us developers.
|
| Developers absolutely should be testing for the issues
| they know about. QA is there to look for unknown issues.
|
| Any company that depends on QA for testing and doesn't
| make devs to it is miserable to work for (both as a dev
| and a QA).
| irrational wrote:
| Not where I work. QA are the ones who first look at all
| reported issues. They see if they can replicate the
| reported issue. If they can't they contact the reporter
| and try to figure out why they can't replicate it. Once
| they can replicate it they write up the ticket with
| replication steps and add it to the backlog to be
| assigned out in a sprint. They attend all meetings and
| explain the issues. Once the developer thinks they have
| fixed the issue they send it back to QA to verify it is
| fixed. Then QA reaches out to the person that reported
| the issue to tell the about the resolution.
| dragonwriter wrote:
| In most places I've worked, having a bug untouched for
| even a fairly small fraction of that time would result in
| someone getting, at a minimum, corrective counseling.
| kortilla wrote:
| Corrective counseling for a single bug? I take it you've
| never worked in a US software company.
| taeric wrote:
| 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.
| aprdm wrote:
| 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
| ricardobeat wrote:
| 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]
| mrighele wrote:
| The affected users didn't bother to check if the issue was
| solved for five years. I think it is fine to close it
| ramphastidae wrote:
| 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.
| bombcar wrote:
| 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.
| 6AA4FD wrote:
| 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 wrote:
| Time for a neomacs?
| distantsounds wrote:
| when your text editor has a better bug reporting feature than
| its text editing feature, maybe it's time you move onto
| something else
| agumonkey wrote:
| 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 wrote:
| 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 wrote:
| As with any large system, improvements to core also risk
| compromising large, popular packages.
| agumonkey wrote:
| I wonder how remacs guys are doing now
| the-smug-one wrote:
| They're no longer taking PRs, development has moved over
| to emacs-ng with a different perspective on how to
| improve Emacs.
| fanf2 wrote:
| There's a new elisp JIT in emacs 28
|
| 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...
|
| a couple of examples of very core features off the top of my
| head
| baby wrote:
| Your comment feels like you've never worked on an open source
| project that gets issues.
| mhils wrote:
| 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 wrote:
| 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 wrote:
| No other approach is sustainable.
| jfrunyon wrote:
| 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 wrote:
| Maybe if the bug is important, someone else will reply to
| confirm? That could be a reasonable line of thinking.
| dmz73 wrote:
| There are two instances I can think of (I've done it
| myself) where the bug is important but user does not come
| back to check on the report after 1 or 2 weeks: 1) Trying
| out different environment and finding things that do not
| work. Report a bug with reproducible example and don't
| check it for a while (months or years) since there is
| important work to be done in working environment. 2) Find
| a bug and then find the workaround since work can't wait
| for external fixes. Report a bug with reproducible
| example, check the status for a few days with no
| responses and then ignore the bug since there is
| important work to be done and workaround has been
| applied. Now you know one of the reasons why "legacy"
| code might look messy - it has workarounds for the bugs
| that may have been fixed...but who has the time to go
| back and check, change, and test the "fixed" code which
| may introduce other bugs.
| Chilinot wrote:
| 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 wrote:
| And if not, the bug is probably not important.
| -\\_(tsu)_/-
|
| At some point, you have to close things. Chances are they
| were spurious, have been fixed or made irrelevant (maybe
| the code no longer exists) or nobody cares.
|
| And if someone does care and it's still an issue, you can
| reopen. It's not as if you are permanently deleting all
| the information for the rest of time.
| jodrellblank wrote:
| Recognising the orignal bug opener's name, Markus Triska,
| I know he's on HN. I checked his username to see if he's
| been active recently and, well, see for yourself:
| https://news.ycombinator.com/threads?id=triska
| dotancohen wrote:
| Not five year. Two months went from the OP in September
| 2015 to the final dev message in November 2015, during
| which the OP and the dev were communicating regularly. It
| was the OP who didn't respond after the dev mentioned
| that he believes that he fixed all the outstanding
| issues.
|
| It was five years later that someone came along and
| closed the bug.
| LanceH wrote:
| I would estimate the chance of a user coming back to
| close a bug at near zero, even after only two months.
| laumars wrote:
| Indeed. As a fellow maintainer I will manually replicate
| the error the user reports, write an test to around the
| failing function, then fix said function.
|
| After that I'm usually satisfied the bug has been fixed.
| So I will link the git commit hash of the fix to the bug
| report and ask the reporter if it fixes the issue their
| side. If I don't hear anything back after a week or two I
| will follow up with a message much like the
| aforementioned: "closing this ticket because I believe it
| to be resolved but happy to reopen if you're still
| experiencing issues."
|
| That is the only way I've found to manage projects
| because you either end up closing tickets prematurely and
| miss bugs, or you end up with tickets open for fixed
| issues that take time and additional mental overhead to
| filter out (both of which are a scarce resource when
| you're trying to balance open source maintenance with a
| full time job and a family).
|
| Two weeks might not seem long but I'm always happy to
| reopen issues. However if users really feel that hard
| done by this approach then they're welcome to submit a
| pull request instead. Or even fork my project and
| maintain that they way they feel it should be done. Maybe
| they'll have more free time than me to filter through
| historic issues that are now fixed but not closed between
| their personal lives and coding time.
| pwdisswordfish0 wrote:
| > ask the reporter if it fixes the issue their side. If I
| don't hear anything back after a week or two I will
| follow up with a message much like the aforementioned:
| "closing this ticket because I believe it to be resolved
| but happy to reopen if you're still experiencing issues."
|
| This tacitly embraces the bugtracker-as-helpdesk/CRM
| mindset, i.e., the GitHub approach, which is what leads
| to things getting so chaotic and unwieldy in the first
| place. It's right in the language--focusing on "their"
| issue. Both maintainers and users need to approach the
| bugracker by recognizing that the scope of any given bug
| report is the bug, and by extension the project, not the
| bug reporter or maintainer. By the time a bug is being
| closed, a maintainer should _know_ (at least with some
| level of confidence--but allowing for them to be wrong)
| whether the bug is fixed or not--because it should be
| well-defined. If the maintainer is not able to do this
| with confidence, it indicates a failure in the practices
| for handling bugs--and possibly (or "likely", in the
| case of a typical project hosted on GitHub) muddled
| scope.
|
| It may be the case that from the user perspective,
| they're still experiencing some issue, but this doesn't
| call for the bug being reopened to handle it. Remember,
| it's not _theirs_ , it's the bug's! If the last report
| led to a real bug being identified, and it really was
| fixed, then leave it closed and figure out if it isn't
| the case that they misidentified the source of the
| discomfort they were experiencing, and if so, have them
| attempt to articulate it, then open a new bug for that.
| Otherwise, you're just treating your bug tracker like a
| message board but splattering it with details from your
| personal TODO list--where "open" and "closed" correspond
| to whether you've decided you're finished with it or not.
| Remember not to think of the bug tracker as yours either!
| It belongs to the project and its bugs. Think of the
| software as a non-human entity and you as a scientist and
| its designated caretaker. It's best to think of the bug
| reporter as a scientist, too--and the elevated
| expectations and responsibility that comes with it.
| yonixw wrote:
| IMO, It is the user responsibility to make a reproducible
| bug (to become a failing test). From there on it is the
| developer responsibility to fix it (make it a passing test)
| ajnin wrote:
| Absolutely. If there is nothing new and a bug is still
| there, there is simply nothing to add to the bug report.
| Too often now bugs get closed automatically for
| "inactivity" after a short period. Should users come back
| every months to "ping" the thread ? Some bugs last for
| years, they'd sooner be blocked for spamming. It's just
| Goodhart's law in action, a cheap way to reduce the bug
| report count.
| lixtra wrote:
| 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 wrote:
| 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.jw
| z.o...
| temp8964 wrote:
| 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 wrote:
| 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 wrote:
| If someone reopens the bug or opens another bug, that is an
| indication that someone still cares.
| userbinator wrote:
| _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.
| tw04 wrote:
| > 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".
| lmilcin wrote:
| 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.
| kesor wrote:
| 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 wrote:
| 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.
| andrey_utkin wrote:
| Dear HNers, would you back a crowdfunding campaign for
| maintenance of a particular open source software you rely on,
| which would have goals like "for the next year, 50% of newly
| reported defects are solved in under a month, 90% in under 3
| months"?
|
| (Surely there's a lot more details to specify to make this a
| reliable bargain.)
| SahAssar wrote:
| Yes, if it was one of those projects that can be "finished" and
| that can set a clear goal for that.
| bern4444 wrote:
| Yes. There's open source software I love and use daily.
|
| Currently for me its neovim. What the maintainers and
| contributors have done is exceptional. They've breathed new
| life into vim (through neovim) and pushed forward broader
| (neo)vim development.
|
| They did (and do) a great job of setting up their goals and
| achieving them. Most notably with their recent .5 release which
| adds support for first class Lua, native LSP, native Treesitter
| support, and more.
|
| > 50% of newly reported defects are solved in under a month,
| 90% in under 3 months
|
| I don't need a commitment like this. It would add unnecessary
| pressure to complete something that may need more time. I feel
| like this would follow Goodhart's law[0] and end up leading to
| overall worse development progress.
|
| [0]https://en.wikipedia.org/wiki/Goodhart%27s_law
| WalterBright wrote:
| This came up a couple days ago:
|
| https://news.ycombinator.com/item?id=28150654
| chrsig wrote:
| >It is cost free. It prevents people from filing it again. It
| provides insight into later problems. It provides a place where
| people can ask and offer advice on working around it. Sometimes
| an intractable bug becomes more tractable later. It can provide
| a clue to a later bug report. Sometimes someone new has a
| brainwave on how to fix it.
|
| I have to disagree at 1) the assertion that it's cost free, and
| 2) it will prevent people from filling it again
|
| re: 1) - it creates clutter, which at least to some individuals
| like myself, can be costly in the form of being
| overwhelming/frustrating/obstructive/etc. YMMV on cost:reward
| on keeping issues open indefinitely. There are other solutions
| like filtering, but if everyone is filtering out untouched
| issues, there's not much difference from closing it.
|
| re: 2) is predicated on issue creators actually searching the
| entire backlog for a pre-existing issue, which they may or may
| not find.
|
| I certainly agree that the issue itself should be kept in the
| tracking system, and continue to be able to be viewed and
| referenced for the reasons you state. Also consider that issues
| can be reopened if they were closed in error.
| antipaul wrote:
| How do we support you? Big emacs fan here.
___________________________________________________________________
(page generated 2021-08-14 23:00 UTC)