[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).


 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/