Re: Olc deployment vs slapd.conf based deployment

[Radovan Semancik <radovan.semancik@evolveum.com>]

Hi,

On 09/18/2017 02:44 PM, Howard Chu wrote:
> These perennial arguments keep coming up. If you want things to 
> improve, contribute. Anyone can write a manpage. Hardly anyone ever 
> does. Everyone sits back and moans while waiting for someone else to 
> fix things for them. That's not what open source projects and 
> communities are about.

I would ... if this was a wiki, or github-like pull request and if there 
was an example of how a good result should look like. But it does not 
make sense for me to spend few hours just figuring out how to contribute 
documentation fix. Especially if I have already figured out how to fix 
my own problem. Well, in fact, I'm quite tempted to try to go down this 
thorny path anyway. Because I like OpenLDAP and I want to help. Just 
every time I see your "how to contribute" page I decide that I will 
leave that for the next time. But I'm quite sure that 99% of users will 
not even look for "how to contribute" page. They need a simple 
"contribute", "edit" or "pull request" button. But, we have discussed 
this before, haven't we?

> In most cases you don't need to write multi-line ldapmodify commands. 
> That's what ordering prefixes are for.

Well, every ldapmodify is either multi-line or 
one-ugly-and-insanely-long-line-that-is-not-really-user-friendly. There 
is a huge difference between "slapdconf add-overlay dc=example,dc=com 
memberof" and equivalent command that is using just ldapmodify.

> > https://github.com/Evolveum/slapdconf
>
> Again, if you want the project to improve - contribute. 3rd party 
> tooling dilutes the knowledge pool. If you think you've improved some 
> aspect of the code, contribute it back to the Project.

Again, it would be probably already contributed to the project if the 
process was more user friendly. But what do I really need to do to 
contribute? First, I have to decide whether I'm OK to contribute under 
OpenLDAP license. The license is not really standard and I have to check 
whether there are some obligations or limitations for my future work. 
Then I need to find the right place in source code, check and update 
coding style (does it apply to perl?), headers, make it part of the 
build and distribution, format the patch (easy part) and submit. Then I 
will probably get criticized for some details in my contribution (yes, 
speculation, but given the overall tone used in this mailing list I 
think it is quite likely). It may easily take few weeks of work for my 
contribution to get accepted. And then I will need to submit every other 
update to the tools as patch. You will probably place the tools in 
"contrib" anyway and you will not spend any significant effort to 
maintain it (again, speculation, but I am right, am I not?). I will need 
to adapt to OpenLDAP release schedule, which, after all these years, is 
still a bit of mystery to me. If I remain the only contributor to the 
tools (which again, is quite likely) then what I will get from this move 
is the same thing as before. But with a lot of extra effort to get 
there. But what is perhaps the worst thing: If I contribute then it is 
not "fire and forget". I need to maintain the code in the long run. And 
if that means more pain to get the same result, you can probably 
understand that I'm not really motivated to contribute.

But, despite all of this, if you like the tools please take them and use 
them in OpenLDAP project. I will gladly change the license and and 
cooperate on inclusion to OpenLDAP project. But we need to find more 
efficient way to cooperate than the way you already have. Until that 
time I'm pretty much OK with a separate github project. Works for me.

--
Radovan Semancik
Software Architect
evolveum.com