[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: overlays
Aaron Richton wrote:
> I'd answer: when does an overlay move from experimental to
> production ready? I'm currently stress-testing some of the
> overlays you listed below
The other side of this is if something is "ready" to be supported.
Certainly QA/stress/etc. is an essential part, but I wouldn't like
the general userbase to have a "production" overlay (or any other
part of OpenLDAP software) that doesn't have decent
documentation/relevant FAQ entries/etc.
By this measure, there's a great deal of OpenLDAP that isn't "ready" to
be supported. Certainly there are large chunks of the code without
corresponding manpages. Of course, I already stated my concerns that
2.3's docs weren't anywhere near usable enough yet for 2.3 to have a
public release. But I suppose now we at least can get more relevant
pointers to which areas need the most attention.
This is also a great
contribution opportunity for the general community (the recent call
for slapo-glue examples on openldap-software was answered very
quickly, for example).
Yes.
I'm not saying that any of the current "experimental" overlays fall
into this category. But if they do, outward display of this ("This
overlay is and always will be experimental," move to contrib, etc.)
would be a very good thing. I'm sure plenty of OpenLDAP users (myself
included) are examining the new overlays for integration into their
environments; a lack of community support (one of the greatest
features of OpenLDAP and open source in general) would surely sway
those decisions somewhat.
A number of the early, experimental overlays went into slapd/overlays
just because I wanted the examples of how to use this API to reside
close by, so they would remain in the foreground of our awareness. Some
of the more recent ones are just there because it is more convenient to
build them that way. Whether they're actually mature enough/worthy of
supported status or not is an open question. Some are there because we
have a commitment to support them (like refint and unique, for which HP
paid Symas to do the initial development).
Anyway, for the "awareness" reasons, I would prefer to keep the
"permanently experimental" overlays where they are, instead of moving
them to contrib. I think the fact that an overlay does not have an
--enable switch in the configure script should be a good indication that
it is experimental/unsupported.
Then there are things like the Password Policy overlay, which due to the
state of its specification, may only be referred to as a "work in
progress" and not as an officially supported feature. This overlay is in
widespread use already; the *spec* is experimental but the code itself
is pretty mature. The experience we gain from having people deploy it is
giving useful data to help shape the further evolution of the spec. As
such, I am quite happy to see it used even more, as long as people
understand the "in progress" nature of the beast, because it helps us
identify where the spec needs more work.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/