[SSSD] [PATCH v2] Add basic support for CI test execution

Lukas Slebodnik lslebodn at redhat.com
Wed Jun 25 21:13:00 UTC 2014


On (25/06/14 22:36), Nikolai Kondrashov wrote:
>On 06/25/2014 10:27 PM, Lukas Slebodnik wrote:
>>On (25/06/14 22:04), Nikolai Kondrashov wrote:
>>>On 06/25/2014 09:54 PM, Lukas Slebodnik wrote:
>>>>On (25/06/14 21:45), Nikolai Kondrashov wrote:
>>>>>Hi everyone,
>>>>>
>>>>>Please find attached v2 of the CI patch.
>>>>>
>>>>>This version pulls Red Hat distro dependencies from contrib/sssd.spec.in.
>>>>>I was able to find a way to do it without resorting to unsafe sudo rules.
>>>>>
>>>>>As before, I would still prefer to move clang/lcov to the moderate set and
>>>>>distcheck/mock to the full set. Is there anyone for/against that?
>>>>>
>>>>>Examples of full test set output on CI machines:
>>>>>
>>>>>Debian Testing  http://sssd-ci.idm.lab.eng.brq.redhat.com:8080/job/new_private_master_debian_testing/57/console
>>>>>Fedora 20       http://sssd-ci.idm.lab.eng.brq.redhat.com:8080/job/new_private_master_fedora20/226/console
>>>>>RHEL6           http://sssd-ci.idm.lab.eng.brq.redhat.com:8080/job/new_private_master_rhel6/6/console
>>>>>RHEL7           http://sssd-ci.idm.lab.eng.brq.redhat.com:8080/job/new_private_master_rhel7/231/console
>>>>>
>>>>Do not paste private link to upstream mailing list. It is not the fist time.
>>>>It is not open source way.
>>>
>>>I agree, posting links to internal resources is not very nice (although more
>>>useful than not) and will remove them. However, I would say that berating
>>>fellow engineers hurts our open source way more.
>
>>If you mean me I will like to see citation, because I have not offended anyone.
>
>I would say the offended is in a better position to conclude that.
>
I did not offended neither you nor anyone else and you didn't prove it with
citation. I am expecting apologize for defamation -> "berating fellow engineers"

I would recommend you to read blog post [1] about a review process.
"Review-Commit" vs "Commit-Review"
With 2nd approach I would have 3 times more patches in sssd on the other
side I would make much much more mistakes.

You should get used to the objections in review process.
There are tree ways how to response:
    a) find 3rd better solution
    b) prove that your version is better (no change)
    c) fix code according to proposal.

>>I've just criticised wrong approach. Firstly in constructive way, secondly
>>strinct NACK.
>
>The problem is the manner. A "please" wouldn't go amiss. Then, last time was
>about a commit message, this time about a message to the maillist, which is
>not the same thing.
In first mail, I used polite version: "It should not be in commit message."
It didn't help and the same mistake happened one more time.

I agree "please" wouldn't go amiss, but without "please" it isn’t impolite
either. It is just shorter.

LS

[1] https://ssimo.org/blog/id_010.html



More information about the sssd-devel mailing list