openldap-devel January 2012

openldap-devel@openldap.org

9 participants
8 discussions

CVS branching -> Git branching model
by Hallvard Breien Furuseth 10 Feb '12

10 Feb '12

I think we should leave the current CVS-style branching model and make better use of Git. 'master' is currently two things: The development branch, and getting in the way it's an abandonware repository: slapmodify, vc, etc. Maybe that's harsh, but if it is not abandonware, why are the authors not finishing it so it can be released? Some of it is years old. The justification for keeping a bunch of features under development in master instead of feature branches was to get more eyes and testers for them. Well, OK, if the features were underway to be finished and released. But that's not working out. So I suggest we reclassify such code as abandonware and throw it out of master. Maybe except code behind #ifdef LDAP_DEVEL which is safe to include in releases. If this prompts someone to finish some code so it can be released, great. Otherwise the reclassification is correct. The code is still in the repo. Someone can recreate it as a feature branch if they care. If some is for RE25, let's make a RE25 branch. If we are going to keep avoiding feature branches and put unfinished stuff in the devel branch, well OK, limited to code which _will_ get released soon and code behind #ifdef LDAP_DEVEL which can be in releases anyway. Otherwise after a while send the author a nastygram, revert the code, maybe re-revert it into a feature branch so it's not forgotten. We can still have a branch with all such unfinished code: See the 'pu' branch in the gitworkflows(7) manpage. It merges the feature branches. RE25 above could be another such branch of merged features. Another issue is that we sometimes want a quick release - normally for a regression in last release - but OPENLDAP_REL_ENG_2_4 is not in shape to be released. So we wait, or end up with a quicka release wich is a bugfix release with some other hopefully-OK code. So, something like the following: - 'maint' branch: Planned releases, like today's OPENLDAP_REL_ENG_2_4. - Temporary 'hotfix' or 'itsNNNN' branches, branched off last release: Quick unplanned releases, when 'maint' is not in shape to be released quickly. After release, merge the branch into 'maint' and delete it. - Some sort of 'devel' branch, branched off 'maint' and current 'master', merging 'maint' after releases. Like to today's 'master' but without unfinished features other than code behind #ifdef LDAP_DEVEL. That way it can be merged into maint now and then (like before a release), which has to be easier than cherry-picking all the time. - Feature branches for long-lived unfinished features. Merged into 'pu' below, and hopefully eventually into the other branches. - 'pu', branching off 'devel' and merging the feature branches, so it looks like today's 'master'. Needs to be thrown away and recreated now and then to avoid clutter. 'maint' or 'devel' above would be named 'master'. I don't care which. Completed feature branches can merge into the branch they branched off. A feature branched off devel cannot merge into maint, since it'd drag devel features with it. So it'd be really nice to keep merging devel into maint now and then, instead of cherry-picking. One final issue, I'd like to get rid of the clutter of old branches and tags from CVS which are no longer of any use. Either delete them, or rename to refs/archive/<heads,tags>/<name>. 'git clone' without '--mirror' will not clone these. -- Hallvard

5 9

RE24 testing call #4
by Quanah Gibson-Mount 01 Feb '12

01 Feb '12

Please test RE24. Recent fixes primarily for back-mdb. Thanks! --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

3 2

RE24 testing call #2 (2.4.29)
by Quanah Gibson-Mount 28 Jan '12

28 Jan '12

A few minor fixes. Please test. Thanks! --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

4 6

RE24 Testing call #3 (2.4.29)
by Quanah Gibson-Mount 26 Jan '12

26 Jan '12

2 fixes for MozNSS. I anticipate this to be the last testing call before tagging for release. Thanks! --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

2 1

RE24 testing call #1 (2.4.29)
by Quanah Gibson-Mount 24 Jan '12

24 Jan '12

Please test RE24. Thanks! --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

2 1

what is the pretty function and the validate function?
by Tianyin Xu 12 Jan '12

12 Jan '12

Hi, all, I'm trying to understand the internal workflow of the attribute type checking and syntax validation in OpenLDAP. For example, if I use an attribute whose syntax is not implemented like "presentationAddress", the log message "no validator for syntax" will occur. I trace this message in the source code and find this's done by checking "pretty" and "validate", as follows: -------------------------------------servers/slapd/modify.c-------------------------------- slap_syntax_validate_func *validate = ad->ad_type->sat_syntax->ssyn_validate; slap_syntax_transform_func *pretty = ad->ad_type->sat_syntax->ssyn_pretty; if( !pretty && !validate ) { *text = "no validator for syntax"; snprintf( textbuf, textlen, "%s: no validator for syntax %s", ml->sml_type.bv_val, ad->ad_type->sat_syntax->ssyn_oid ); *text = textbuf; return LDAP_INVALID_SYNTAX; } ----------------------------------------------------------------------------------------------------- Moreover, the pretty function and validate function are treat differently in the latter code like: if ( pretty ) { rc = ordered_value_pretty( ad, &ml->sml_values[nvals], &pval, ctx ); // wrapper for pretty function } else { rc = ordered_value_validate( ad, &ml->sml_values[nvals], ml->sml_op ); // wrapper for validate function } I'm very confused on the "pretty" function and the "validate" function. I tried to google but no related results. Could anyone tell me WHAT is the pretty function and what is the validate function? And HOW can OpenLDAP knows which function is pretty and which is validate? Sorry for the newbie question. Thanks a lot!!! Best, Tianyin -- Tianyin XU, http://cseweb.ucsd.edu/~tixu/

1 0

back-monitor API: monitor_subsys_t
by Ondrej Kuznik 10 Jan '12

10 Jan '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I'm looking over back-monitor's interface to get some more monitoring to back-ldap, mainly operation count, just like the one in cn=operations,cn=monitor and finishing the connection monitoring in ldap_back_monitor_conn_create. There is a part of the monitor API that is a bit unclear to me: In order to register an entry with register_entry(), one needs a monitor_subsys_t structure, but how to obtain one? Is it a back-monitor's job to appoint one or the monitored backend's? The only use of this structure outside back-monitor is back-ldap again, not relying on anyone when populating the structure, however a comment directly above that code reads: "set up the fake subsystem [...]", where the "fake" reads to me as "we shouldn't need one at all". I understand the monitoring in back-ldap is functionally a stub with the infrastructure *mostly* done, so maybe there was a rewrite of the relevant code planned? What else should I take into consideration and/or be looking into during my efforts? - -- Ondrej Kuznik -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7l9F0ACgkQ9GWxeeH+cXuehwCglecsXz589XJq7g0ciHRstplp sNcAnA6DnU/elucCWUlOMF0mORVyvqLm =2C+Q -----END PGP SIGNATURE----- This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

3 2

back-monitor and compare operation
by Ondrej Kuznik 10 Jan '12

10 Jan '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, while in progress of adding further monitoring capabilities to the back-ldap backend I stumbled over a weirdness in how the monitor handles the COMPARE operation: If a compare request is issued, the entry is retrieved directly from the monitor cache, triggering no updates, thus the outcome of that comparison is based on outdated or default information (depends on when an update was last triggered). As a minimum example, having a fresh instance of cn=monitor (that you have not searched since startup) compare the monitoredInfo attribute of cn=Uptime,cn=Time,cn=monitor to "0", you should get LDAP_COMPARE_TRUE. I've been forced to make a small change to the back-monitor subsystem API locally (will upload the patch shortly), so I could fix this too now that I've become familiar with the code a bit. - -- Ondrej Kuznik -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8MTUwACgkQ9GWxeeH+cXvU8gCfUayFypwDbByJMFWorjgCYI+r bZUAnRt0bQz11hazctXc5Gn72+by3+9N =SPg/ -----END PGP SIGNATURE----- This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you for understanding.

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel January 2012