kmail sigh

[Colin Close]

On Tuesday, 30 January 2018 15:13:06 GMT Pablo Sanchez wrote:
> [ Comments below, in-line ]
> 
> On Tue, 30 Jan 2018 10:09:36 +0000, Colin Close wrote:
> > Hi Pablo,
> 
> Hi Colin,
> 
> > I haven't created any bugs because, as you have observed it is
> > notoriously difficult to describe.
> 
> Please don't take this the wrong way ... I just want to state a
> reality for me, as a developer (not of KDE).
> 
> In order for me to solve a problem, I generally need a repeatable test
> case.  If I have a crushing load of work, incomplete bug reports will
> fall to the wayside.
> 
> No bug reports, means the onus is on me to go out and look for bugs.
> But if I have a crushing load of work, there's very little time to do
> that.
> 
> > Since there was no response last time I posted this I assumed that
> > the problem was already known.
> 
> Unfortunately I think that's a very bad assumption.
> 
> > I'm happy to provide some screen shots and the like if that will
> > help make the situation clearer. Put as simply as possible the
> > sequence runs like this.
> 
> What I am going to suggest will take work but in the end, it would
> make your bug report more likely to get addressed.
> 
> Goal
> ====
> Create stand-alone reproducible bug reports.
> 
> Make it as easy as possible for a developer to set up their
> environment to reproduce the bug.
> 
> How
> ===
> o Create a test email account (e.g. a burner gmail account)
> o Create a new Linux user
> o Login as the new user
> o Set up kmail to use the test email account
> o Create the reproducible bug
>    + Detail the exact steps taken
>    + Provide screen shots where clarity will help
> o Test your bug report by replicating the above with yet another new
>    Linux user and test email account.
> 
> Keep things brief.  Not walls of text.  :)
> 
> > [ trimmed ]
> 
> Cheers,
> --
> Pablo Sanchez - Blueoak Database Engineering, Inc
> Ph:    819.459.1926        iNum:  883.5100.0990.1054

Hi Pablo,
I quite appreciate the need for a "reproducer" this a common thing that 
developers ask for and is a reasonable request. 
The trouble with this is that it does not address the real world. To create a 
sane reproducer for this bug is not so easy as it sounds as it is possible 
that the issues occur because of the large volume of mail/headers that are 
being processed. Creating a small scale installation may not create the same 
conditions thus to be representative I need to work with the data and mail 
accounts that I have since this is the real world situation. There is already 
growing evidence that some of the issues are load dependent as postgresql 
seems to perform better than the mysql variants.  

I believe I have provided enough information for you to pinpoint the area of 
code where the failure of fsck is taking place. It is quite evident from my 
report that the part of the code that selects the duplicate to delete from the 
database is flawed in that it is deleting a mail with no body content. The 
fact that there is a mail with no body content in the first place is a 
different bug.  If it is possible to simply fix the fsck bug this would give 
users who have these issues a way forward which at the moment they do not 
have.

Obviously I will try and find a way to create a simple reproducer in a 
separate account and see what happens but this I supect will be time consuming 
with the possibility of failure.

As a possible alternative if you as someone who knows the code intimately 
could point me to the code that performs this function I will attempt to try 
and debug it myself. I am familiar with SQL and database structures though I 
am not a C or C++ coder but can understand enough to probably spot what is 
going wrong. 

I will file an initial bug with any detailed information I can get from my 
current installation so at least the issue is flagged.

Best,
Colin Close

QA Lead 
OpenMandriva