openldap-devel

openldap-devel@openldap.org

1416 discussions

tab-width 4 (was: commit: ldap/servers/slapd/back-ldif ldif.c)
by Hallvard B Furuseth 18 Jan '10

18 Jan '10

Please use tab-width 4 like most of the rest of the code. Unless you are in a tab-width 8 file, anyway. This mixture of tab-width 4 and 8 keeps misaligning more and more of the code, one line here and one there over the years. In this case the 'struct ldif_tool' contents, which was aligned until now. Look at it with 'less -x4' or something if you haven't done so. Same with slap.h, which still does look better with tab-width 4 than 8, despite having been mixed up quite a bit by now. -- Hallvard

1 0

Re: OpenLDAP 2.5
by Kurt Zeilenga 14 Jan '10

14 Jan '10

On Jan 14, 2010, at 1:57 AM, Simon Wilkinson wrote: > > On 14 Jan 2010, at 02:24, Kurt Zeilenga wrote: >> >>>> You can't do that with a git merge, >> >> Yes you can. We do in at my day job all the time. >> >>>> because the commit on HEAD includes >>>> the history of everything else on head, which you definitely don't >>>> want to pull into the branch. >> >> Individuals commit on their own local clones, and use 'git push' onto the project's trunk. Release engineers can then cherry-pick the trunk patch onto their local clone of the release branch and push to the project's release branch. > > That's a cherry-pick, rather than a merge. Yes, that's what I said. > There's an important difference here - cherry-picks create a completely new object, where as a merge causes the same object to be applied to both branches. Merges make it much easier to see visually what's been applied where, but they do require that you commit to branch, then merge to trunk. Oh, and they only work at all if there's no back, or forwards, porting required. As the branches will diverge, the process needs to account for porting issues. > >>>> I'd also strongly recommend that you take a look at Shawn's "gerrit" >>>> tool. This provides a code review tool for patch submission, and >>>> hugely simplifies the process of controlling push access to a git >>>> tree, and reviewing the changes that you accept. >> >> We've never had any restrictions on commits. > > Presumably you don't allow anyone on the internet commit access to the repository! Never had any restrictions enforced by the repo software (e.g., CVS). We only have system access restrictions, enforced today by who has ssh access or not. > That's the big advantage with gerrit - that it provides a way of managing internet wide commit access. Developers set up ssh keys through a web interface, and can then be given commit access to a project. You can let trusted developers push straight into the tree, and require everyone else to use code review, or you can mandate review for everyone. At OpenAFS, we've found that using gerrit has really increased the pool of people we get code submissions from, as it makes it trivially easy for them to push changes to us. It also massively simplifies the process of reviewing which changes should and shouldn't go in. See http://gerrit.openafs.org/ for our instance, or http://review.source.android.com for the Android one. I don't see any reason, at least at first, manage access as we do with our CVS repository. Committers get ssh access to the main repo, no git-enforced restrictions. The world gets anonymous access to a read-only clone. > >>>> I'm happy to talk to you about OpenAFS's experiences in all of this, >>>> if you'd like more details. >>> >>> Absolutely, thanks for the offer. Up till now my use of git has been extremely >>> basic. It wouldn't bother me too much to continue the CVS-style workflow we've >>> had, >> >> I would strong recommend that one should not change both repo software and engineering process at the same time. First, switch repo software. Learn it. Then, if consider changes the workflow. > > Yes - that was pretty much the approach we decided upon. We've kept our cherry-pick based workflow from CVS. The big git change has been that rather than patches going into a bug tracking system for consideration, and then being pulled out of there and pushed into CVS by a small set of commiters, changes now get pushed directly into gerrit by their submitters. This means that, for the commiters, the process of applying the change is a button press or two, which has hugely speeded up our rate of change. The least change to our processes would be for the random developers (not committers) to submit git patches to our issue tracker which our committers can, upon acceptance, git-am onto their trunk clone and push from their. This is actually just a submission format change, not a change in processes or work-flow. -- Kurt

1 0

Re: OpenLDAP 2.5
by Howard Chu 13 Jan '10

13 Jan '10

Simon Wilkinson wrote: > > On 5 Jan 2010, at 18:33, Quanah Gibson-Mount wrote: > >> --On Tuesday, December 22, 2009 7:40 PM -0800 Howard Chu <hyc(a)symas.com >>> wrote: >> >>> With 2.4.21 out, and hopefully stable enough to promote to the next >>> Stable release, it's time to feature-freeze 2.4 and prepare for the >>> 2.5 >>> branch. As I already announced to the OpenLDAP-Committers, we're also >>> planning to switch from CVS to GIT in mid-January. Commits for 2.5 >>> will >>> begin after we've settled into GIT. >> >> Yeah! One question from the RE side, is how to best handle 2.4 >> fixes with HEAD getting further & further apart. > > You also want to consider how git's tools for branching and merging > fit together. We went through this with OpenAFS last year, guided by > some very helpful conversations with Shawn Pearce. Basically, the > fundamental question is whether you want a merge based workflow, one > based around cherry-picks, or some hybrid version of the two. > > If you have a merge based workflow, then the model is that you make > that change on a branch, and then merge that branch into the head. > OpenAFS (and OpenLDAP, by the sounds of things) had a model where we > committed to HEAD, and then 'pulled-up' to the relevant branches. You > can't do that with a git merge, because the commit on HEAD includes > the history of everything else on head, which you definitely don't > want to pull into the branch. So, we ended up deciding to cherry-pick > pullups. This makes it harder to tell whether we've missed anything > that should be pulled up, but "git cherry" helps ease that pain, and > it means we keep our existing workflow. > > I'd also strongly recommend that you take a look at Shawn's "gerrit" > tool. This provides a code review tool for patch submission, and > hugely simplifies the process of controlling push access to a git > tree, and reviewing the changes that you accept. > > I'm happy to talk to you about OpenAFS's experiences in all of this, > if you'd like more details. Absolutely, thanks for the offer. Up till now my use of git has been extremely basic. It wouldn't bother me too much to continue the CVS-style workflow we've had, but if there are better ways that involve less manual labor, we certainly want to know. (Though frankly, the fact that git is faster and works from a complete local repo was convincing enough for me. Being able to perform local commits to save and backtrack my work-in-progress without requiring network access is already a huge gain.) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Re: commit: ldap/servers/slapd sasl.c
by Hallvard B Furuseth 06 Jan '10

06 Jan '10

rein(a)OpenLDAP.org writes: > ITS#6441 cyrus-sasl 2.1.24 auxprop_lookup plugin returns status. > > +#if SASL_VERSION_FULL >= 0x020118 If it's for 2.1.24, checking for 2.1.18 looks somewhat suboptimal. -- Hallvard

2 2

ACL check parameters
by Howard Chu 05 Jan '10

05 Jan '10

oprofile shows quite a bit more overhead in 2.4's ACL processing vs 2.3's. I'm thinking of streamlining things a bit, along these lines. Any thoughts? This acl.c compiles, but a fair amount of slapd code needs to be altered to use it. I guess if we commit and move forward on it it will have to be for 2.5. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

3 7

Fwd: Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
by Howard Chu 05 Jan '10

05 Jan '10

So, what do folks think about reviving libldif as an exported piece of the distribution? -------- Original Message -------- Subject: Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif Date: Thu, 17 Dec 2009 03:46:08 GMT From: hyc(a)symas.com To: openldap-its(a)openldap.org rmeggins(a)redhat.com wrote: > I think this could be accomplished in one of two ways: > 1) Just have libldif return lists of struct berval* for the various data > parsed. The caller would be responsible for turning these into LDAPMod > or LDAPControl structures - the advantage is that libldif doesn't have > to know about any of these higher level structures > 2) Have libldif create LDAPMod and LDAPControl - I think this could be > accomplished by having ldif.c #include<ldap.h> to pull in the > definitions of LDAPMod and LDAPControl - would this be ok? Let's move this discussion to the openldap-devel mailing list. I'm thinking (2) is OK but I'd like to hear from other developers / potential users of this library. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

4 4

static assertions
by Hallvard B Furuseth 21 Dec '09

21 Dec '09

I think we should insert a number of static assertions in the OpenLDAP code: Asserts that fail or succeed at compile time. E.g. for the comment in config.c:bindkey[] (ITS#6419). Like this - in include/ac/assert.h? Or ldap_cdefs.h in case we want to use it in installed headers? /* Declaration which tries to force a compile error if !cond */ #define ber_static_assert(cond) \ LBER_V(LDAP_CONST char) ber_assertion[ber_assertz(cond) + 1] /* Return 0, or if !cond try to force a compile error */ #define ber_assertz(cond) (sizeof(struct { \ int ber_assert1[(cond) ? 9 : -9], ber_assert2:(cond) ? 9 : -9; }) && 0) /* Usage: */ ber_static_assert(~0U >= 0xFFFFFFFFUL); /* int = 32 bits or wider */ int foo(int i) { return i + ber_assertz(LDAP_SUCCESS == 0); } liblber will need a dummy variable 'const char ber_assertion[1];'. We can drop that if anyone dislikes it: ber_static_assert() can take an assertion_name parameter and declare a typedef based on that name. Or it can generate a name from __LINE__. Then we can have only one static assert per line, which matters for macros but little else. -- Hallvard

2 3

RE24 testing call #1 (2.4.21)
by Quanah Gibson-Mount 16 Dec '09

16 Dec '09

All commits for the upcoming 2.4.21 release have been integrated. Please test. Thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

6 5

Re: commit: ldap/servers/slapd bconfig.c
by Ralf Haferkamp 10 Dec '09

10 Dec '09

Am Donnerstag 10 Dezember 2009 14:22:26 schrieb ralf(a)openldap.org: > Update of /repo/OpenLDAP/pkg/ldap/servers/slapd > > Modified Files: > bconfig.c 1.404 -> 1.405 > > Log Message: > global limits can also be set in "cn=config" (more forITS#6428) While working on this, I learned that the global limits can either be set in the "cn=config" entry or in "olcDatabase=frontend,cn=config". Is there a special reason for this? This seems also to be the case for some other attributes: olcSecurity, olcRestricted, olcRequires. Just to name a few. -- Ralf

2 1

Re: commit: ldap/servers/slapd config.c syncrepl.c
by Hallvard B Furuseth 09 Dec '09

09 Dec '09

hyc(a)OpenLDAP.org writes: > ITS#6419 also init for ldaps:// URIs Does it work for ldapi:// as well? (And should it?) I seem to remember StartTLS does work for ldapi, though I don't know what a sensible host name in the server cert would be in that case. -- Hallvard

5 6

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel