On Tue, May 4, 2010 at 3:34 AM, Eugene Indenbom <eindenbom(a)gmail.com> wrote:
Dear SSSD developers,
I am writing this e-mail to express my utter disappointment and
disillusionment with bazaar or community development at least as it
applies to SSSD.
I started a new project in the middle of February and have chosen IPA
and SSSD as SW platform for projects LDAP/Kerberos domain. I am working
with (and programming for) Linux since 1995 and starting from year 2000
I was looking for a decent solution for Linux domain. It was very
obvious from the very beginning that dedicated system security
daemon/service is required for domain to function properly and reliably.
So I jumped at SSSD and IPA as they were my dreams and years-old desire
coming to reality.
To my bitter disappointment nothing has functioned properly or even
functioned at all. You can dig into Red Hat's bugzilla for the bugs I
have filed. They would illustrate a number of problems I had to solve
prior my domain was usable at all.
And the biggest headache was SSSD. It crashed, it failed to restart
after an update, it returned system errors during authorization leaving
me no choice other than to use fall-back local file authentication.
Please keep it technical. There is no need to be emotional because one
of the developers didn't completely agree with your approach. In the
long run, they have to maintain this codebase on an enterprise linux
release for years to come, not you. Think about that for a minute. In
my experience, the sssd developers have been friendly and very
helpful. In fact, I have the exact opposite experience as you.
However, I've not tried to get any patches accepted into the sssd and
so I understand your frustration. Granted, they have disagreed with me
from time to time, but it was on technical basis and in the end they
were correct. Try to look at it from their shoes instead of flaming
the mailinglist. It is not the right thing to do.
Well I have decided: this is community work on the bleeding edge of
Linux and Open Source development and I can help not only my project,
but the community to deliver a robust Linux domain. So I invested
substantial amount of my personal time in fixing the problems in SSSD
and submitted the results to the SSSD development list.
What response have I got?
On 04/13/2010 06:44 PM, Simo Sorce wrote:
> On the 4th I'll try to do a bit more analysis later, but it looks a bit
> too complicated and out of style. In particular I don't like much the
> sdap_id_op idea and the associated _create() function. I will try to
> give some more constructive feedback on it later.
Nobody has ever considered my work for possible inclusion into upstream.
The only thing that disturbs Simo is how to find a good reason not to
include and to ditch my work.
It has taken me more than a month to convince Simo and others that
problems I have stated are valid, require attention and must be fixed.
You can dig into e-mail exchange and find out that all the objectives of
my patch are acknowledged, but the solution is not.
On 04/30/2010 06:53 PM, Simo Sorce wrote:
> On Fri, 30 Apr 2010 11:49:57 +0400
> Eugene Indenbom<eindenbom(a)gmail.com> wrote:
>> PS I still do not understand what is wrong with my patches. Why is it
>> not possible just to use them and not to redo the job?
> To be honest, I think it is too complex.
And now the final blow comes. Simo's patch has comparable level of
complexity and Simo has admitted that:
On 04/16/2010 10:22 PM, Simo Sorce wrote:
> Note that the patch still includes my old changes to avoid freeing
> ctx->gsh, they are *not* necessary, but I think they are good hygiene
> anyway so I left them in.
So this patch is only "good hygiene", it provides no functionality, it
solves no problem, but it breaks all my efforts. And it is accepted and
included into master.
On 05/03/2010 01:21 PM, Sumit Bose wrote:
> ACK to both.
> I have seen Eugene comments on the patches and do not want to argure
> that these patches make the code only cleaner and more robust. But I
> think these improvements are still worth to be added to the current code
> base and some of them might get lost if we postponed them to a later
And how about my work, will it be lost? After Simo's patch I have to
rewrite my solution as it conflicts with Simo's changes and I have to
retest them. What for? It will never be accepted.
The whole situation is a canonic illustration for NOT INVENTED HERE
Talking about code quality and testing of the LDAP provider, I was
devastated by the very poor code quality. There are other parts of SSSD
code that are good written and well commented. But not LDAP provider.
Hundreds of lines of duplicated code, copy and paste work making every
bug to replicate itself up to 7 times. I am not joking: one piece of
faulty code that caused the problems is duplicated 7 times. There is
code duplicated in the same file for no reason. Is it really hard to
make a function doing common job?
And testing. It looks like that nobody ever tests changes to LDAP
provider. In released SSSD 1.1 IPA provider simply aborted SSSD daemon
(see bug https://bugzilla.redhat.com/show_bug.cgi?id=576856
). The same
story with patches submitted for review. For example, no testing has
been done on patch submitted on April 13.
I've found a few segfaults actually, but most of them were very
promptly hunted down and fixed. Only one had time to make it to their
bugtracker. This is bleeding edge software after all. There will be
And again my work is not good enough although it has been tested in
__only__ IPA/SSSD domain.
So I would like to ask Stephen Gallagher to modify Wiki Contributions
Page according to the actual status:
No help is needed and no contribution will be accepted.
You realize that sometimes in the linux kernel development, people
have to submit their code a dozen or more times to get it accepted
right? Quality matters when you have to support something for a long
time. What would happen if everyone took their ball and went home?
This is no way to act in a "community". What about the embedded ARM
port and work that George McCollister has done for this project? That
was certainly a community effort and is accepted upstream now for the
benefit of all. Not seeing your point of view completely does not make
PS This is my last e-mail to SSSD Development mailing list. I
unsubscribe from it now as the whole business is obviously fruitless.
cc'd so you actually get this email. It is a hopefully helpful response.
Don't drink and derive, alcohol and analysis don't mix.