Re: Olc deployment vs slapd.conf based deployment

[Ondřej Kuzník <ondra@mistotebe.net>]

On Mon, Sep 18, 2017 at 06:08:16PM +0200, Radovan Semancik wrote:
> On 09/18/2017 05:20 PM, Howard Chu wrote:
>> Radovan Semancik wrote:
>>> 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.
>> 
>> So you're still saying, it's fine for other people to put in the hours to
>> produce something you benefit from, but it's too much trouble for you to
>> contribute in return. And in the meantime, it's perfectly OK for you to
>> sit back and complain that things haven't been fixed. Got it.
> 
> I'm afraid that you haven't got the point. According to my experience people
> are willing to contribute. I'm willing to contribute. Just the barrier is
> too high. But the worst thing is that I feel that the barrier could be much
> lower if there was a bit of will to lower it. But the will is just not
> there. And I do not see why. It is not 1990s any more. There are ways how to
> make cooperation easier. Why not use them?
> 
> I'm willing to do the work. In fact, I did some work already. Much more than
> just few hours. I'm just not willing to overcome unreasonable barriers that
> take a lot of time, do not significantly increase quality of the product and
> make my future work miserable. I would rather invest that time to make the
> software better. And that is exactly what I'm going to do.

I'm a bit concerned that a complaint about how contributing a completely
new tool to the project might seem not worth the hassle[0] has provoked
a thread which has since shifted to problems about general contribution
to the project but still revolving around the same arguments whether
they transpose well or not, so you end up talking past each other. No
disrespect meant, but this is not helping the community or the project
(its codebase).

This is a popular project in terms of usage (isn't the library itself
installed on a majority of UNIX systems?) that is simultaneously quite
complex[1]. It is maintained by a very small team and little in the way
of capacity to process existing contributions quickly and attract new
ones. Yes, in my eyes, the project needs to grow or it will die
eventually - how many subsystems have been marked as 'experimental' for
years?.

On Tue, Sep 19, 2017 at 10:54:56AM +0200, Radovan Semancik wrote:
> [...]
> In addition to that github has hooks that can be
> used to direct the comments directly to the mailing list. The best solution
> that I have seen is probably in the Apache CXF project where pull request
> comments are automatically synchronized with bug tracking system comments.
> There is always a way ... if there is a will.
> 
> What I see as a major problem is that there is no will. OpenLDAP project
> clearly needs major improvement. But there are almost no contributors to
> improve the project. I'm trying to explain that there may reasons why people
> are not keen to contribute. But what I see as a response only makes all of
> this worse. I'm sorry about that. Really sorry.
> 
>> You could still use "format-patch" to send your change requests via
>> E-Mail.
> 
> You could still write your letter by hand, put it into envelope and send it
> by post. But we are usually not doing that these days, are we? I'm quite
> sure we all know the reasons.

That is not a situation that's pleasant or helpful to you, but just
adding another way to contribute is not the silver bullet[2]. There are
successful projects that request contributions in way of patches (Linux,
PostgreSQL, just to quote the better known), and the IPR policy is
dictated by the foundation and unlikely to change, so let's stop
complaining about these policies in principle. On the other hand,
suggestions to making their implementation better, especially while
committing to make it work and help maintain it(!) are AFAIK
appreciated.

In terms of that, some of us would like to have a different bug tracking
system, if it supports attaching patches to it I guess that's something
you'd find a bit more welcoming.

I'd like to improve this, simplify things and make them more transparent
if I can and if you want to help, you're welcome as well, but please be
constructive, just re-hashing discussions about things that go against
fundamental policy[3] and only add more work for questionable benefit
does not seem constructive to me. Start small if you don't want the
responsibility to maintain things indefinitely, and to give an example,
I think merging documentation patches has been quite hassle-free and
time to merge quite short.

Ondrej

[0]. And the same arguments apply pretty much everywhere in the OSS
world, so while most are completely valid, they might not be entirely
fair
[1]. Hell, I don't understand half of its codebase after 8 years since
I've first been exposed to it
[2]. Not to mention that this only increases the workload for people
processing the submissions (e.g. how much work will get duplicated)
[3]. Some of it AFAIK dictated by how Kurt set it up with the foundation

-- 
Ondřej Kuzník
Senior Software Engineer
Symas Corporation                       http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP