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_deb...
>>>>Fedora 20
http://sssd-ci.idm.lab.eng.brq.redhat.com:8080/job/new_private_master_fed...
>>>>RHEL6
http://sssd-ci.idm.lab.eng.brq.redhat.com:8080/job/new_private_master_rhe...
>>>>RHEL7
http://sssd-ci.idm.lab.eng.brq.redhat.com:8080/job/new_private_master_rhe...
>>>>
>>>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