[Date Prev][Date Next]
Re: 2.3.43, and a variety of problems.
On Fri, 18 Sep 2009, Francis Swasey wrote:
2.4 is not "stable" by any definition other than the OpenLDAP project has
designated it so.
I would disagree with this. I'm not at all involved in the official
project designations, and I can say that I gave a talk at Rutgers in March
2009 (2.4.15 at the time) saying that RE24 is suitable for production use.
It's on all of my replicas in production, and has been for months. One of
the large reasons it's not on my master is because I've been spending my
"OpenLDAP time" on RE24 testing (for the entire community) rather than my
I am still seeing people complaining about syncrepl problems. So, how about
you developers stop adding all the new wiz-bang bells and whistles and
concentrate on stability and performance?
Honestly, I think this sort of answers the whole point: we're talking
about a fairly "small" project, and I'd rather see those limited resources
applied to stability and performance moving forward. Backporting to RE23
would distract from time needed towards making a "perfect" RE24 (or RE25
I don't know how it would be taken if somebody wanted to open up
"openldap-legacy" to attempt backports. My guess is it'd all be fine until
there's some seriously incompatible change, at which point you'd either
need a good dev team (to do a fork) or to say "this effort is over, go to
RE++." The former is extremely tough to come by, and the latter is
essentially where we are today, so from a pragmatic standpoint I might
even argue we're as good as we can be with the current model.
Have you fixed the fact that 2.4 is so much slower than 2.3 as reported by
Quanah two months ago yet?
Quanah already pointed this out to some extent: I find the performance
comparisons fallacious. Part of RE24 development has revealed some fairly
serious issues in back-bdb, and there's a lot more locking in the code now
to account for that. The perceived speed of RE23 really doesn't matter if
it can't produce proper results. After all, if you want *real*
performance, just define mutex_lock/unlock to be noops. I guarantee you
you'll get good ops/second, during the limited time it runs at least...