[SSSD] [PATCHES] PAM: authenticate agains cache

Lukas Slebodnik lslebodn at redhat.com
Tue Jun 30 21:41:21 UTC 2015


On (30/06/15 10:33), Pavel Reichl wrote:
>On 06/29/2015 02:56 PM, Lukas Slebodnik wrote:
>>On (29/06/15 14:17), Pavel Reichl wrote:
>>>On 06/29/2015 11:56 AM, Lukas Slebodnik wrote:
>>>>On (26/06/15 17:31), Pavel Reichl wrote:
>>>>So it seems you still do not understand what's wrong from desing point of view.
>>>>If you do not understand something please ask it before. We would save your
>>>>time with preparing patches and time of other developers reviewing unnecessary
>>>>round of patches.
>>>Sorry, that you feel that way.
>>>
>>>I don't agree with essence of your concerns. I don't think I'm forcing new
>>>paradigm into SSSD. You  can discuss this topic with pbrezina, I'm sure he
>>>has plenty to say.
>>I'm sorry I do not see any correlation between your patches and pbrezina.
>>He does not include inconsistencies into sssd. He mostly reduces them.
>What I had in mind was that pbrezina has recently shared with me his ideas
>about development of SSSD and he mainly emphasized his extensive usage of OOP
>principles that he uses while developing SSSD. I suppose that he might want
>to discuss some of your opinions like:
>
It's fine if it is implemented in consistent way.

>>However sssd is written in C and in procedural (imperative) paradigm.
>>Even though I prefer other paradigm as well. I will not try to
>>create an abortive hybrid.
>Alas he is on PTO now so we have to wait for his input.
>
>>
>>>introduced 2 new functions into sysdb which operated on
>>>higher level than other functions in sysdb. I can agree that this was not
>>>completely consistent with the rest of sysdb API but I don't think I was
>>>lowering the quality of code.
>>I didn't say that code has low quality. So please either quote
>>or do not put words in my mouth.
>>I wrote many times that it is inconsistent approach. We have many hacks/
>>inconsistencies in sssd so we needn't introduce a new one.
>Sorry but in my opinion there are only 2 reasons to NACK a patch:
>1) it's not working correctly
>2) there are problems with code quality (code inconsistency belongs here IMO)
>
Software engineer are used to thinking in binary way. Real word offer more
choices. I know it is your opinion and I cannot influence it.
But there are more reasons why patch should not be accepted.

a) bad design (code may look good and work but design is strange)
b) missing unit tests for critical parts of code
...

LS



More information about the sssd-devel mailing list