OK, if no new issues are reported against HEAD in the next 24 hours then I think tomorrow we should kick out a new 2.4alpha.
Offhand it looks to me like syncrepl enhancements are the only thing missing for a Beta. Anyone else have a list of items they want to resolve for 2.4?
If Ando's comment that Solaris poll() isn't working yet is true, I'd like to see that work out. It wasn't clear to me whether he was implicating slapd or Solaris, though...is there a next step here? (set some autoconf to force poll() and make test, perhaps?)
On Thu, 1 Feb 2007, Howard Chu wrote:
OK, if no new issues are reported against HEAD in the next 24 hours then I think tomorrow we should kick out a new 2.4alpha.
Offhand it looks to me like syncrepl enhancements are the only thing missing for a Beta. Anyone else have a list of items they want to resolve for 2.4? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/
Aaron Richton wrote:
If Ando's comment that Solaris poll() isn't working yet is true, I'd like to see that work out. It wasn't clear to me whether he was implicating slapd or Solaris, though...is there a next step here? (set some autoconf to force poll() and make test, perhaps?)
No, there's no autoconf switch. You just need to make sure SLAP_X_DEVPOLL is defined when slapd/daemon.c is compiled, and then be prepared for sparks.
On Thu, 1 Feb 2007, Howard Chu wrote:
OK, if no new issues are reported against HEAD in the next 24 hours then I think tomorrow we should kick out a new 2.4alpha.
Offhand it looks to me like syncrepl enhancements are the only thing missing for a Beta. Anyone else have a list of items they want to resolve for 2.4?
Note the wording - I didn't ask for items "you want resolved (by someone else)" - that list would be a lot longer. I'm polling for what any developers have in-progress that they would like to have included, or what they plan to get finished by then.
What I'd like resolved, but don't have time to get to yet: cn=config support for all the remaining backends and overlays that still need to be converted: back-dnssrv - this has no config options, so all it needs is an empty cf table to shut up the warning. back-meta - depends on many other things, primarily librewrite back-null - oddly enough, this has a config option... back-passwd - has 1 option back-perl - complicated because it can pass arbitrary options to the underlying perl module. We can still accomodate this using something like a perl- prefix or a olcDbPerlConfig: attribute, just like how we handle DB_CONFIG. back-relay - depends on librewrite / slapo-rwm back-shell - easy enough back-sql - haven't really looked
It looks like the majority of the overlays have been converted. rwm is still a problem. collect.c, dyngroup.c, retcode.c, seqmod.c are all trivial.
Manpages for the useful overlays that are missing them would be nice. I'm not so worried about collect.c or seqmod.c since they aren't actually meant to be used, they're only meant as coding examples.
On a side-note, when I was benchmarking the connection manager I found it useful to doctor up back-null to actually return an entry in response to search requests. If anyone else would find this useful, I can commit that patch.
Howard Chu wrote:
Aaron Richton wrote:
If Ando's comment that Solaris poll() isn't working yet is true, I'd like to see that work out. It wasn't clear to me whether he was implicating slapd or Solaris, though...is there a next step here? (set some autoconf to force poll() and make test, perhaps?)
No, there's no autoconf switch. You just need to make sure SLAP_X_DEVPOLL is defined when slapd/daemon.c is compiled, and then be prepared for sparks.
On Thu, 1 Feb 2007, Howard Chu wrote:
OK, if no new issues are reported against HEAD in the next 24 hours then I think tomorrow we should kick out a new 2.4alpha.
Offhand it looks to me like syncrepl enhancements are the only thing missing for a Beta. Anyone else have a list of items they want to resolve for 2.4?
Note the wording - I didn't ask for items "you want resolved (by someone else)" - that list would be a lot longer. I'm polling for what any developers have in-progress that they would like to have included, or what they plan to get finished by then.
What I'd like resolved, but don't have time to get to yet: cn=config support for all the remaining backends and overlays that still need to be converted: back-dnssrv - this has no config options, so all it needs is an empty cf table to shut up the warning. back-meta - depends on many other things, primarily librewrite
Apart from rewriting, back-meta shouldn't be a big deal; it just has really a lot of statements, and shares a lot of them with back-ldap, occasionally on a per-target basis.
back-null - oddly enough, this has a config option... back-passwd - has 1 option back-perl - complicated because it can pass arbitrary options to the underlying perl module. We can still accomodate this using something like a perl- prefix or a olcDbPerlConfig: attribute, just like how we handle DB_CONFIG. back-relay - depends on librewrite / slapo-rwm back-shell - easy enough back-sql - haven't really looked
This should be trivial, there is no ordering issues, just a bunch of statements.
It looks like the majority of the overlays have been converted. rwm is still a problem.
I think the real problem is that shortcuts like "suffixmassage <DN> [<DN>]" actually are converted to a bunch of librewrite statements which may make little sense to those who don't like configuring librewrite directly. Or, if someone mixes up suffixmassage and direct statements, things may get weird. A plain approach would be to just pile up those statements in an X-ORDERED bunch of values; this is supposed to work as expected.
collect.c, dyngroup.c, retcode.c, seqmod.c are all trivial.
Manpages for the useful overlays that are missing them would be nice. I'm not so worried about collect.c or seqmod.c since they aren't actually meant to be used, they're only meant as coding examples.
On a side-note, when I was benchmarking the connection manager I found it useful to doctor up back-null to actually return an entry in response to search requests. If anyone else would find this useful, I can commit that patch.
For a similar need, I typically use back-null(5) with slapo-retcode(5), configured to return an entry with successful/error response code.
p.
Pierangelo Masarati wrote:
Howard Chu wrote:
On a side-note, when I was benchmarking the connection manager I found it useful to doctor up back-null to actually return an entry in response to search requests. If anyone else would find this useful, I can commit that patch.
For a similar need, I typically use back-null(5) with slapo-retcode(5), configured to return an entry with successful/error response code.
Neat trick. Maybe put than in the example in the slapd-null(5) manpage?
-
Aaron Richton -
Hallvard B Furuseth -
Howard Chu -
Pierangelo Masarati