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:
>>>>>>Please find attached v2 of the CI patch.
>>>>>>This version pulls Red Hat distro dependencies from
>>>>>>I was able to find a way to do it without resorting to unsafe sudo
>>>>>>As before, I would still prefer to move clang/lcov to the moderate
>>>>>>distcheck/mock to the full set. Is there anyone for/against that?
>>>>>>Examples of full test set output on CI machines:
>>>>>Do not paste private link to upstream mailing list. It is not the fist
>>>>>It is not open source way.
>>>>I agree, posting links to internal resources is not very nice (although
>>>>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
>>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
>I would recommend you to read blog post  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,
>>The problem is the manner. A "please" wouldn't go amiss. Then, last
>>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
>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
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
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
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
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
person in control and the only one responsible (which is simply untrue).
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
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
party. This is counterproductive to effective cooperation, it makes
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
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
"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