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

Lukas Slebodnik lslebodn at redhat.com
Thu Jun 26 07:10:36 UTC 2014


On (26/06/14 03:12), Nikolai Kondrashov wrote:
>On 06/26/2014 12:13 AM, Lukas Slebodnik wrote:
>>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.
>
>"Please" is normal level of politeness in civilized conversations. Lack of
There is big range of levels between politeness and impoliteness.
Without "please" or any other softeners (could you, it would be good ...)
it will be in the middle. (neutral)

I haven't used impolite frases.
    e.g: "your code is crap"
         "fix your shit"


>normal politeness in requests generally indicates lack of consideration. When
>enforcing, lack of normal politeness indicates scolding.
There is big difference between objection and scolding.
The free dictionary says:
    scolding == A harsh or sharp reprimand.

I didn't criticise you. I criticised approch. There is *HUGE* difference.
I provided reasons why approch was bad and provided solutions.
CI is about simplificationa and automatisation of developers tasks.
You started working on CI but you don't have experiences with SSSD development
and review. You needn't be aware of problematic way. I pointed them out, but
you didn't accepted them. I would reccomend you to more listen (read opposite
arguments). In another words: to walk in others shoes.

>I received a scolding
>from you for an action. Which action doesn't matter (but see below), because
>you're my peer, a fellow engineer, to whom I am obliged no more than you are
>obliged to me. So, yes, I'm offended.
>From mentioned blog post:
"R-C requires active intervention from the reviewer".
There were problematic parts in you patch and I didn't (don't/ won't) ignore
them. You should expect objections. Nobody is perfect, nether me nor you.

>I joined this project because I found it interesting, and I'm as much
>interested in its success as you are. I wouldn't join otherwise, it will just
>be dishonest and lame. And I would say every engineer on this team has the
>same motivation. So, there is no call for scolding to "improve" it. I would go
>as far as to say scolding works *against* motivation.
>
My main motivation is to improve code and 1st part is proper review. I don't
want to overlook problems. It won't solve them.

>We all make mistakes. I certainly do, and so do you. We would all be pretty
>upset, if we scolded each other every time. So please, be considerate, polite
>and accept basic human nature.
>
You take it personal. There is nothing personal. The problem was with approach
and ignoring my good advices.

>In almost every argument with me you show that you consider yourself the sole
>person in control and the only one responsible (which is simply untrue).
I saw problems which you didn't see. You didn't provide better solution and
didn't accept my proposal. It wasn't constructive discussion from your side.
I felt like scratched gramophone record. I repeated valid arguments and you
ignored them.

>You often use "I", instead of "we", excluding the opponent from the interested
I used we:I 50:50 I will use "we" in future more often.

>party. This is counterproductive to effective cooperation, it makes people
>feel unwelcome. And, while at the end of the day Red Hat employees *have* to
>cooperate, it probably has worse effect on outside contributors.
>
>Now, back to the "mistake" in question. You said originally about my CI RFC:
>
>    The host is not accesible. It should not be in commit message.
>
>And I complied. Assuming private URLs in git history were unwelcome and seeing
>reasons behind that, I moved them to the e-mail message, which is *not* commit
>message (and I said that before, which you either ignored or haven't noticed).
>However, you claim that I made the same mistake, which is untrue. I didn't
>remove them altogether, as they're useful to understanding the workings of CI,
>if only to the few privileged Red Hat employees.
There is not difference between private link in commit message an mail in
public mailing list. If you want to send links to internal host you should use
internal mailing lists.

>Then, please don't lecture me about the usefullness and practice of pre-commit
>reviews. I've been participating in them since about 2008, including kernel
>reviews since 2010, which are stricter than SSSD reviews. I also advocated,
>implemented, and trained others for pre-commit reviews in SSSD QE, where they
>seem to still work. So, yes, I know the drill.
>
>Perhaps, "berating" was too strong a word, and "scolding" should be used
"scolding" is inapropriate as well. I did not use swear words.
Every time, I used valid objections in neutral tone.

We need to solve it and I am expecting apologize for defamation -> "berating
fellow engineers". You just replace word "berating" for "scolding" but it is
not excuse.

LS



More information about the sssd-devel mailing list