On Fri, Jan 16, 2015 at 8:07 AM, Shai Berger wrote:
On Friday 16 January 2015 01:45:53 Michael Gilbert wrote:
However, the problem reported here is not a usability problem. If a mail
client losing record of which mails have been read and which haven't
isn't non-serious data loss, I can't
On Sun, Jan 18, 2015 at 5:44 PM, Shai Berger wrote:
I am asking about serious vs. non-serious because those are the terms used
by reportbug (non-serious data loss is a reason to mark a bug grave).
Both grave and critical refer to actual data loss. Using the term
serious isn't particularly
On Monday 19 January 2015 00:54:41 Michael Gilbert wrote:
On Sun, Jan 18, 2015 at 5:44 PM, Shai Berger wrote:
I am asking about serious vs. non-serious because those are the terms
used by reportbug (non-serious data loss is a reason to mark a bug
grave).
Both grave and critical refer to
On Sun, Jan 18, 2015 at 6:18 PM, Shai Berger wrote:
Both grave and critical refer to actual data loss. Using the term
serious isn't particularly useful since that falls outside those two
categories anyway.
Again, you're being tautological, repeating your terms rather than defining
them.
On Sun, Jan 18, 2015 at 4:14 PM, Shai Berger s...@platonix.com wrote:
So, the bits marking messages as read or unread are not data? What,
pray tell, are they?
Easily recreatable bit flags.
So data isn't lost if it is easily recreatable? Really?
No.
By that argument, there really
On Sunday 18 January 2015 23:51:01 Michael Gilbert wrote:
On Sun, Jan 18, 2015 at 4:14 PM, Shai Berger s...@platonix.com wrote:
Those easily recreatable bits represent a significant part of my mail
workflow. Almost any data can be recreated by repeating the work that
created it. Your claims
On Sunday 18 January 2015 21:46:52 Michael Gilbert wrote:
On Fri, Jan 16, 2015 at 8:07 AM, Shai Berger wrote:
On Friday 16 January 2015 01:45:53 Michael Gilbert wrote:
However, the problem reported here is not a usability problem. If a
mail client losing record of which mails have been
On Friday 16 January 2015 01:45:53 Michael Gilbert wrote:
However, the problem reported here is not a usability problem. If a mail
client losing record of which mails have been read and which haven't
isn't non-serious data loss, I can't tell what is.
Actual data loss.
So, the bits
However, the problem reported here is not a usability problem. If a mail
client losing record of which mails have been read and which haven't isn't
non-serious data loss, I can't tell what is.
Actual data loss.
Best wishes,
Mike
--
To UNSUBSCRIBE, email to
Hi Michael,
On Wednesday 14 January 2015 04:45:16 Michael Gilbert wrote:
This is a usability problem, so it doesn't really qualify as release
critical.
Debian developers get to call the severity of bugs in general, and the
criticality for a specific release in particular.
However, the
control: severity -1 important
It may sound cynical, but my advice would be that if you're hit with this,
change mail clients :/
In the context of freeze/release, I'd suggest to tag this jessie-ignore, or
even forever-ignore.
This is a usability problem, so it doesn't really qualify as
These kinds of problems have plagued kmail for many, many years, dating
back to the beginnings of kmail2 (at least). As we can see from the
numerous upstream bugs, there is also no shortage of reports (IIRC, I
filed one myself for fake duplicates years ago). Perhaps upstream
doesn't care, or
Hey,
it is hard to descide witch upstream bug matches best:
https://bugs.kde.org/show_bug.cgi?id=276856
https://bugs.kde.org/show_bug.cgi?id=288208
https://bugs.kde.org/show_bug.cgi?id=278737
https://bugs.kde.org/show_bug.cgi?id=294074
https://bugs.kde.org/show_bug.cgi?id=285063
I think the
13 matches
Mail list logo
