Live data from Hacker News

Thunderbird 140 “Eclipse”

blog.thunderbird.net

221–230 of 297 posts

Re: Thunderbird 140 “Eclipse”

#221

Earlier quoted context omitted.

Okay, let's assume more diagnostics and guards were added. Now re-answer the above questions with these assumptions. - How do you fix a bug you can't reproduce? - How do you *close* a bug report when you can't reproduce? Being generous here, we're assuming there's 17 years worth of diagnostics and safety guards added but through that time the bug still isn't reproducible. Let's try to answer the questions under these…

If you've added guards and diagnostics, then you close it until someone else files a follow-up, then it can be re-opened. There's no sense keeping it open unless there are ongoing reports of the issue.

There are users in the comments here reporting the issue affects them.

Would some noble purpose be served by closing the existing issue in the hope that they'll complain via more official channels?

Re: Thunderbird 140 “Eclipse”

#222

I wanted to love Thunderbird, used it for years then a bug [0] literally deleted all my emails. I regularly see updates of people understandably raging on the ticket :( It's a bug that literally deletes user data from both the server and the client without warning. It's been open and confirmed for 17 years straight. It could happen to you. How is it not top 1 priority to fix it? [0] https://bugzilla.mozilla.org/show_…

Oh, wow. When I have to use Thunderbird, I never move emails. I manually copy emails to a folder and delete the emails from the old folder after that. I forgot why I have to do this. Now I know again. A lot of people here are speculating that this bug must be very rare. I maintained like 30 Thunderbird installations for other people. This bug bit me at least twice. It can't be that rare.

Re: Thunderbird 140 “Eclipse”

#223
post #159

Earlier quoted context omitted.

This is very interesting, thanks for sharing details. A friend with strong corrections in their glasses always mentions they feel like they can't see much in the dark, not as much as other people anyway, but we've never been able to quantify it (that they don't see something that I do). That you always wear them in the dark sounds to me like it's indeed more important to correct this effect for dark backgrounds, whic…

It’s not ghosting, it’s halation as that bloke said. Bright things do not leave a trail, instead they are just blurry. If I see a white LED in the dark, the LED shows some sort of smear at a certain angle and with a certain length. The length of the smear decreases the closer I get to the LED. It doesn’t change ever, even if days pass, because it’s a static deformation inside my eye. It does not leave a trail if I lo…

Oh! I see, I guess the "then look at a bright surface" part of that other post made me think of that an image stays with you for a short time (a ghost image), but I get what you mean now

Re: Thunderbird 140 “Eclipse”

#224

Earlier quoted context omitted.

You have to remember that when Gmail was launched it was considerably better than most desktop mail clients at the time. There was never a time when GMail was better than plain old Outlook, but this is coming from someone to whom IMAP has always seemed like a really terrible solution in search of a nonexistent problem. My email database is important to me, and worth managing locally, as this thread more than adequate…

I don’t see how IMAP would prevent you from having old emails

If you're going to keep them all locally anyway, what's the point of IMAP?

(Admittedly my judgement was formed at a time when one user, one device was the rule. I suppose if mobile access to email is important, there's a good argument for keeping the data server-side. I solve that problem with VNC.)

Re: Thunderbird 140 “Eclipse”

#225

Earlier quoted context omitted.

I don’t see how IMAP would prevent you from having old emails

If you're going to keep them all locally anyway, what's the point of IMAP? (Admittedly my judgement was formed at a time when one user, one device was the rule. I suppose if mobile access to email is important, there's a good argument for keeping the data server-side. I solve that problem with VNC.)

I’m not going to keep all of them locally, but that doesn’t mean I lose access to any of them. I can instantly access all my emails from 20 years ago.

As you mentioned I do access my email from several different devices, and each one having a different subset of my emails would be absolute hell.

I’m curious, do you log onto your computer from your smartphone in order to access your email?

Re: Thunderbird 140 “Eclipse”

#226

Earlier quoted context omitted.

Sometimes , treating a facetious/sarcastic request seriously helps disarm the facetiousness. Other times, it does not.

English is my first language but I don’t understand this use of “disarm”.

You counter the facetiousness in a way it stops spreading and possibly even spark a constructive discussion is how I understand it (ESL though). I certainly observed this phenomenon myself (although as the person being facetious, I often feel like "I was joking, I actually agree, that's indeed what I was actually implying, but good you made it clear and explicit I guess")

I guess you'd disarm the person being facecious rather than the facetiousness, like you'd disarm someone about to cast you a magic spell.

Re: Thunderbird 140 “Eclipse”

#227

Earlier quoted context omitted.

and then they simultaneously determined "yeah, we might eat your data. Lets not warn anyone about that AT ALL, lets keep the feature activated and let them users lose their data". This behavior ought to be criminal.

> Lets not warn anyone about that AT ALL, lets keep the feature activated and let them users lose their data How did you conclude this? IDK why the assumption is that safety measures haven't been created. You wouldn't mark the bug as resolved if you put in safety features, right? You * ONLY MARK AS RESOLVED* after reproducing the bug and * VERIFYING* that it won't happen again. Right? Dear god I hope this is what you…

I'd agree with you that the fact that the bug is still open after 17 years isn't the problem, but the issue is that people are still (as of 10 months ago) running into the issue of their mail being deleted. If they'd secretly implemented "safety measures" as you suggest that wouldn't be happening.

Looking at the timeline, it's possible that they've addressed a few of the bugs that result in data loss several years ago, and it's possible that the latest guy who ran into the problem within the last year triggered it in new ways or under new conditions but it's clear that the problem of thunderbird deleting messages from the server when copies haven't successfully been saved during a move operation wasn't solved by any "safety measures" 9 months ago and it's doubtful that it's been solved now.

My guess is that because thunderbird ultimately doesn't bother to make sure that messages are successfully and accurately copied before it removes them from the server it'll only be a matter of time before someone else stumbles on some other set of circumstances which results in data loss when messages are being moved.

Re: Thunderbird 140 “Eclipse”

#228

Earlier quoted context omitted.

Make no mistake - I am not absolving them of leaving this issue unaddressed lol just saying if it was easy they’d likely have handled it. It’s probably difficult or they just don’t know, so they keep putting it off and decided that not enough users are affected for real consequences (which is wrong to do)

i fully understand it might be very hard to fix, but to know about it for that long, and not warn people or disable the functionality is unforgivable

Totally agree

Re: Thunderbird 140 “Eclipse”

#229

Earlier quoted context omitted.

Okay, let's assume more diagnostics and guards were added. Now re-answer the above questions with these assumptions. - How do you fix a bug you can't reproduce? - How do you *close* a bug report when you can't reproduce? Being generous here, we're assuming there's 17 years worth of diagnostics and safety guards added but through that time the bug still isn't reproducible. Let's try to answer the questions under these…

If you've added guards and diagnostics, then you close it until someone else files a follow-up, then it can be re-opened. There's no sense keeping it open unless there are ongoing reports of the issue.

  > There's no sense keeping it open unless there are ongoing reports of the issue.
I think you've misunderstood. There's other options.

Let's consider this from a failure analysis standpoint. Here's our options

  - You have incorrectly marked issue as solved
  - You have incorrectly left the issue marked as unsolved
*Which error case would you rather have?*

The classic example of this design choice is with a safe. Let's imagine you are building a safe. If the safe fails, would you prefer that it fails into a state that is unlocked or into a state that is locked? The answer isn't so obvious, as it actually depends on how it fails, right?

A very common example is when designing skyscrapers. The choice is that when a skyscraper fails, there is a strong preference that it falls in on itself (think 9/11). Why? Because if it falls to the side then it takes out other buildings and can create a chain reaction (a related famous example being housing in Industrial Revolution London and fire...)

Your action is a valid option, but it is not the option that I would chose. I think what they did was perfectly fine. They left it open (to avoid tricking anyone to thinking it is solved when the status of solved is actually unknown) and marked with additional information about lack of verification/reproducibility. Essentially, it is marked as stale.

So we're back to the earlier question:

  - How do you *close* a bug report when you can't reproduce? 
Or we can frame differently: "How do you close a bug report if you have no indication that the bug was resolved nor exists?"

Re: Thunderbird 140 “Eclipse”

#230

Earlier quoted context omitted.

If you've added guards and diagnostics, then you close it until someone else files a follow-up, then it can be re-opened. There's no sense keeping it open unless there are ongoing reports of the issue.

There are users in the comments here reporting the issue affects them. Would some noble purpose be served by closing the existing issue in the hope that they'll complain via more official channels?

Hopefully those people will report the issue in the bug report and try to help the devs reproduce the issue. Especially since it is linked.
Post reply on HN