[Date Prev][Date Next]
Re: Some openldap fixes...
Please remember that OpenLDAP is community developed. The
community makes it what it is. You are welcomed to participate
as you see fit. The community is open to all.
However, don't be surprise when changes thrown over a wall
end up on the floor. You have to help us help you. We
do so because helping you helps us.
I have a job, too. I (and my employer) are willing to take
time away from my primary task to help integrate changes
contributed by others. As far as doing things for fun, I
do most everything because it's fun. My job is fun, that's
why I took (er... created it) it. I'll quit the day it's not.
Working with contributors is fun.
Let's get back to the code, that's fun....
At 10:16 PM 9/18/00 +0200, Marijn Meijles wrote:
>geef ff wat commentaar
>> As the patch you provided is quite large, includes changes covering
>> many issues, and is against a version not under active development
>> (1.2 is only "maintained"), it is likely we need to discuss
>> and determine an appropriate course of action.
>I am aware of the fact that it's a 'dead' branch. However, when we started,
>we could choose between 2.0-alpha, which was not quite stable at the time,
>and the 1.2.x branch. Back then I had no idea that we would end up fixing
>so much stuff.
>However, that's why we tried to give an idea of the things we have fixed, so
>other people could say "hey, that's cool for the next release" or "hey, I
>could use some help with this or that". Although we
>are both quite busy, we are willing to integrate stuff into the next
>major release, because that's were most of our stuff would go. But keep
>in mind we're still working for a company, so it also needs to have
>some value for the company.
>Another 'problem' is that we didn't do it just for fun. We need the
>features we've implemented. As major enhancements go into the developing
>branch, we would be forced to use that branch. The code in a -devel
>branch is not always stable enough for our use. In fact, even 2.0 crashes
>after about 15 seconds of the load our own backends endure all day. I guess
>I could look into this when I'm bored ;).
>The next thing I want to say is that because all our fixes are
>functional, we would not always agree on things. For example, 2.0
>stores onelevel and subtree relationships in dn2id. The insertion
>and removal of entries involves processing of ALL the parent nodes.
>We have tried the same scheme with our new indices, but found that this
>was too slow during changes, as well as during lookups. So we came up
>with something faster. We place more emphasis on overall speed while you
>seem to be happy when it works.
>And last but not least, we're doing this job next to our studies. If
>we only had the job, we would have ported the changes to 2.0-alpha
>a long time ago, just for the heck of it ;)
>If at first you don't succeed, destroy all evidence that you tried.