<div dir="ltr">No problem Simon.<div><br></div><div>I would just to inform that comments are not populated in bugzilla. For the story, all can be lost. As comments are long and constructive, i think it's important for QA.</div><div><br></div><div>Best</div><div><br></div><div>Gilles</div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-03-24 10:00 GMT+01:00 Simon <span dir="ltr"><<a href="mailto:bugzilla_noreply@kde.org" target="_blank">bugzilla_noreply@kde.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><a href="https://bugs.kde.org/show_bug.cgi?id=377587" rel="noreferrer" target="_blank">https://bugs.kde.org/show_bug.<wbr>cgi?id=377587</a><br>
<br>
--- Comment #6 from Simon <<a href="mailto:freisim93@gmail.com">freisim93@gmail.com</a>> ---<br>
Below are three emails concerning this issue posted to the developer mailing<br>
list. Apparently I wrote quite a few comments to bugs by email which never<br>
reached the actual bug. Sorry if I spammed the mailing list with tries to get<br>
it to work (I didn't).<br>
<span class=""><br>
On 24/03/17 04:32, Gilles Caulier wrote:<br>
> Simon,<br>
><br>
> I agree with Andrew. Point 2/ is more logic in this scénario.<br>
><br>
> Note : Why this story is not fully in bugzilla file ? Somebody has<br>
> responded directly by mail to the bugzilla notification and the file is not<br>
</span>> updated as 377587 <<a href="https://bugs.kde.org/show_bug.cgi?id=377587" rel="noreferrer" target="_blank">https://bugs.kde.org/show_<wbr>bug.cgi?id=377587</a>> comments...<br>
<span class="im HOEnZb">><br>
> I recommend to backport missing comments in bugzilla to not lost full<br>
> story.<br>
><br>
> Gilles<br>
><br>
><br>
><br>
> 2017-03-24 1:00 GMT+01:00 Andrew Goodbody <<a href="mailto:ajg02@elfringham.co.uk">ajg02@elfringham.co.uk</a>>:<br>
><br>
>> My vote is for 2) - always do what you're told and only what you're told.<br>
>> Give as much control to the user as possible, do not do unexpected things.<br>
>> Using a different config and/or creating a new one is very unexpected. I<br>
>> see no reason to assume the config would be colocated with the database,<br>
>> that's a very strange idea.<br>
>><br>
>> Andrew<br>
>><br>
>><br>
>> On 23/03/17 11:48, Simon Frei wrote:<br>
>><br>
>>> Thanks for the clarification, I get your scenario now. So it is a<br>
>>> trade-off between no side-effects and data safety. I still think that a<br>
>>> user using the command line options should be aware of the difference<br>
>>> between config and database and therefore be in charge of using<br>
>>> sensible/safe options. However planning for the DAU is also a good idea.<br>
>>><br>
>>> I would like to hear what Gilles/Maik/Mario/... think about this.<br>
>>> Recap: The question is which of these options is favourable (arguments<br>
>>> in the comments above):<br>
>>> 1. Set config to the same directory as --database-directory. If no<br>
>>> config file exists there, create a new one/copy over the default one<br>
>>> (still respecting --config if given).<br>
>>> 2. Always use the default config unless --config is given, also with<br>
>>> --database-directory.<br>
>>><br>
>>><br>
>>><br>
<br>
</span><div class="HOEnZb"><div class="h5">--<br>
You are receiving this mail because:<br>
You are the assignee for the bug.</div></div></blockquote></div><br></div>