On (01/09/14 20:44), Nikolai Kondrashov wrote:
On 09/01/2014 07:48 PM, Michal Židek wrote:
>>My response and plan here would be similar to the Valgrind's case. Only
>>here we may perhaps disable certain error classes for the start, or use
>>Clang augmentation in the code, making ignore the difficult issues, but in
>>the end we should arrive to the same binary status.
>>
>
>About Valgrind and Clang, I think you underestimate the amount of time
>that is in front of us before we get to the binary PASS/FAIL state.
Perhaps, but I'd like to try it. If it turns out so, with Valgrind we can
-1
still use suppressions and I'll try finding something similar for
Clang.
-1
>Until then, these checks are completely useless and only take time
(which is
>one of the reasons why I wanted to be able to disable/enable specific
>steps).
As automatic checks they are useless, but they're still providing an easy way
to run Valgrind and Clang to help people fix those issues.
Yes, I understand why you'd want to skip them and I expect there will be more
tests people would like to skip or run alone. Perhaps we can simply move both
Valgrind and Clang to the "rigorous" test set for now.
>The number would tell us if something changed from the past run or not.
>(and would make these steps less useless). It would be a valuable
>improvement IMO.
It could be, even though we won't be able to tell if one failure disappeared
and another one appeared. But I'd like to try for something better first.
It's better to see at least count of failed test than nothing (current state)
Explanation of -1s:
Support for Global Catalog was added in sssd 1.11, but it wasn't done in nice
way. The reason was that there wern't lot of time and id had to be implemented.
The problematic part is that sssd expected to have just one connection to the
LDAP server. In another words, we need to refactor ldap provider. The bad side
of refactoring is that you will create regressions. They cannot be found by
unit tests, because source code will be different and unit test will have to be
rewritten as well. Andthere are also other parrts hich should be refactored.
***This is a reason why we need high level tests.***
Trying to fix all valgrind warnings (mostly memory leaks) will not have a big
benefit. We use different way of checking memory leaks in tests
(see src/tests/leak_check.c). The similar situation is with clang warnings.
We used to comparing warnings before official release.
Please focus to the different tasks, these parts have very low priority.
LS