[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Olc deployment vs slapd.conf based deployment
- To: Howard Chu <hyc@symas.com>, openldap-technical@openldap.org
- Subject: Re: Olc deployment vs slapd.conf based deployment
- From: Radovan Semancik <radovan.semancik@evolveum.com>
- Date: Mon, 18 Sep 2017 17:02:38 +0200
- Content-language: en-US
- Dkim-filter: OpenDKIM Filter v2.9.0 hermes.evolveum.com CBC9236486F
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evolveum.com; s=46F1F96C-8266-11E5-BB5D-6C9186186C84; t=1505747021; bh=bTjnRBSM/CSQefZ0OkHhkTJbg8KQkaZUuSe6sXw73uU=; h=Subject:To:From:Message-ID:Date:MIME-Version:Content-Type: Content-Transfer-Encoding; b=d9YSDksZEihYcvn80FRbSpZG4UKs0qk4HRZWys46syVUMIMplt2pm4rfw6euOmiE2 gKXXaQkBGyMagwz1VRwf7AI0Uh20pJ5rowr9Z4weUqHzKPg8dE5AY7k/3eKye1wtIi qb97Slt0erxI7tSKfUhV08W2UMbe7FmzAeoFi1iU=
- In-reply-to: <824383ab-fa88-94fd-da21-e722b667afed@symas.com>
- References: <CALm_VjikYjnYEcrfKXYjm8AFt0VQ7EV1crGX=tXst3-RUbr7fQ@mail.gmail.com> <WM!5ccf6f006a0b3aa9abfbc3f9c9be3eb021708e582b17a98c6ed49d59b8e29485947e7650 daf5ed804e3554164491fa2d!@mailstronghold-1.zmailcloud.com> <78567B9241600A3CA0EAC7A6@[192.168.1.30]> <b9e230a5-1dc0-b01f-ae4d-d23e0cd21d3e@stroeder.com> <b7d93005-3de5-5b9a-630e-d93510bd9b44@ironicdesign.com> <WM!c441031e673082de9904bb70fc818ffda9b9f7dd5392e09c37cc5ccb7332246257b6daf5a456f233f94aa06df0aea0f3!@mailstronghold-1.zmailcloud.com> <77336596566E63C254BF34B5@[192.168.1.30]> <3508b356-63a5-f91d-6ba3-d885a2ff0529@evolveum.com> <WM!3fb2737abcf7ce658a2017237acce334aff67bc1b6f36234483c863f1f6b0780401faf87184181aa4bd7d7390143e9ca!@mailstronghold-2.zmailcloud.com> <824383ab-fa88-94fd-da21-e722b667afed@symas.com>
- User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
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