<div dir="ltr"><div>Hi Steve,<br><br>Thanks for taking a look. I'll take another look at the PR4: I think I can split a few bits out in a more granular fashion and that should make it easier for you.<br><br></div><div>That said, I would prefer to take the PRs in the order I posted them because otherwise it is hard for me to track what is and is not "done", especially as you sometimes end up changing what actually gets committed to KDE/master; that effectively creates yet another fork for me to have to reconcile. Ideally, I'd like us to use the PR process and let me do the commit to KDE when we are happy: the whole point of having all the branches and PRs split out the way they are is to make this tractable and to allow me to incorporate your comments in a systematic manner. As we deal with each PR, I can rebase and rewrite the subsequent PRs.<br><br></div><div>I hope that sounds OK.<br></div><div><br></div><div>Shaheed<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 4 February 2017 at 12:09, Stephen Kelly <span dir="ltr"><<a href="mailto:steveire@gmail.com" target="_blank">steveire@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Stephen Kelly wrote:<br>
<br>
> Simple, short and noiseless commits are easy to review, so please see if<br>
> you can follow suit there.<br>
<br>
</span>In particular, I tried to review the commit "Rule database structure<br>
changes", but it seems to contain lots of unrelated things such as<br>
outputting 'discarded' instead of 'suppressed', and lots more. That is all<br>
noise and makes the commit hard to review.<br>
<br>
Please reduce that commit to the change in rules_SipTest.py plus whatever<br>
minimum change is needed to the python code to support that. The rest of the<br>
changes can either be follow-ups or can appear before the API change commit.<br>
<br>
Thanks,<br>
<br>
Steve.<br>
</blockquote></div><br></div>