[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: OpenLDAP 2.5 plans and community engagement



On Thu, Jul 25, 2019 at 08:16:27AM +0200, Ulrich Windl wrote:
> Ondrej Kuzník <ondra@mistotebe.net> schrieb am 24.07.2019 um 20:01 in
> Nachricht <20190724180157.ut3r62pdgiaemjdt@mistotebe.net>:
>> Another issue frustrating both users and contributors to the project
>> has been the existing jitterbugs bug tracker (a.k.a. ITS), which has
>> by now outlived its usefulness. Plans to move to a project-hosted
>> Gitlab instance + Bugzilla (via Gitlab's built in Bugzilla
>> integration) are being made and this should make the issue tracker
>> searchable again, help with triage as well as greatly improve the
>> visibility into our release process. Especially after the migration,
>> this would be another opportunity for anyone with just a bit of
>> spare time to help by triaging open issues so we can make timely
>> releases of better quality.
> 
> Using Bugzilla can't be wrong it seems. Most issue trackers are just worse
> (from the perspective of users at least).

It is popular and maintained by upstream.

>> I'm sure everyone agrees our website could do with a redesign. We've
>> started looking into this but it has been a slow process so far and
>> if you can contribute here, that might speed things up. It doesn't
>> need much, keeping it a collection of static html pages, just a
>> slight reorganisation of the content that is more friendly to anyone
>> visiting it for the first time plus a simplistic design along the
>> lines of many other open source projects (openssl.org for example)
>> would go a long way.
> 
> Personally I don't like sites that use too much script code,
> especially for download links. It would be great if the site still had
> minimal functionality when scripts are unavailable or disabled.

I agree here that any redesign should be perfectly useable with JS
disabled.

>> The FAQ site however is on the opposite side of the spectrum and will
>> be removed at some later point. There have been two suggestions how
>> to replace it. We could use Gitlab internal wiki or a static webpage
>> site based on Gitlab pages and we want to transfer over articles that
>> are still relevant.
> 
> I have no strong opinion on that, but what about this idea: Allow up/down
> votes for individual questions and answers (a bit like stackexchange sites).
> Then remove those entries with significant down votes, while keeping those with
> up votes.

I think the idea was to keep all those that are still salvageable, just
copy them over to the wiki and retire the FAQ software altogether. I'm
afraid we don't have anyone willing to add new functionality to
something that is essentially dead already.

> Next step could be to add references to official documentation to the answers
> (a good exercise to check whether the documentation is clear and sufficient):
> When eventually deciding to retire the FAQ, integrate the remaining FAQs not
> answerable from the rest of the documentation into some other document.

That could still happen after we've migrated to the wiki?

>> Let us know what the pain points have been with OpenLDAP when you
>> were just starting, right now and if you have a suggestion how to
>> make it easier to start using it. Or if you wanted to contribute, has
>> anything discouraged you?
> 
> Maybe some type of "Read me first" document that could contain a
> "decision flow graph" dealing with a new installation or an upgrade.

That sounds good in principle. Would you be willing to drive this?

>> Thanks ever so much for reading this far. This email is long enough
>> already so I will follow up with another one about my long term plans
>> to overhaul the test infrastructure and other tools that might be
>> worth introducing to help with setting up and managing OpenLDAP
>> deployments.
> 
> What I don't like is the strong focus on one (LMDB) database backend, despite
> of all the stupid things Oracle does.

There are big issues with the two BerkeleyDB backends for many
installations so it had to be abandoned. I'll let Howard or Quanah take
this part of the discussion further should they choose to.

Unfortunately, no other backend is in shape to be useable as a main
database in production.

Thanks,

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