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

Nikolai Kondrashov Nikolai.Kondrashov at redhat.com
Thu Jun 26 00:12:30 UTC 2014


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
normal politeness in requests generally indicates lack of consideration. When
enforcing, lack of normal politeness indicates scolding. 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.

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.

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.

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). You
often use "I", instead of "we", excluding the opponent from the interested
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.

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
instead, I'm not sure, English is not my native language. If it is so, then I
apologize for that, but not the rest of my statement. I would have liked an
apology from you, but I understand it is unlikely to happen.

I will avoid continuing this discussion and heating this up further, if I can
help it, as that costs me too much energy and peace of mind.

Let us focus on the review of the patch.

Thank you.

Sincerely,
Nick



More information about the sssd-devel mailing list