CVS branching -> Git branching model
by Hallvard Breien Furuseth
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
11 years, 7 months
RE24 testing call #4
by Quanah Gibson-Mount
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
11 years, 7 months
RE24 testing call #2 (2.4.29)
by Quanah Gibson-Mount
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
11 years, 7 months
RE24 Testing call #3 (2.4.29)
by Quanah Gibson-Mount
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
11 years, 7 months
RE24 testing call #1 (2.4.29)
by Quanah Gibson-Mount
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
11 years, 8 months
what is the pretty function and the validate function?
by Tianyin Xu
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/
11 years, 8 months
back-monitor API: monitor_subsys_t
by Ondrej Kuznik
-----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.
11 years, 8 months
back-monitor and compare operation
by Ondrej Kuznik
-----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.
11 years, 8 months
