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
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 cr
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 particul
On Sunday 18 January 2015 23:51:01 Michael Gilbert wrote:
> On Sun, Jan 18, 2015 at 4:14 PM, Shai Berger 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 essentia
On Sun, Jan 18, 2015 at 4:14 PM, Shai Berger 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 sho
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 ha
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",
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
> 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 debian-bugs-dist-requ...@list
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 p
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 a
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 it
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 under
13 matches
Mail list logo
