[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Antw: OpenLDAP 2.5 plans and community engagement
>>> Ondrej Kuzník <ondra@mistotebe.net> schrieb am 24.07.2019 um 20:01 in
Nachricht
<20190724180157.ut3r62pdgiaemjdt@mistotebe.net>:
> Hi all,
> as 2.4 has finally stabilised and the ITS list is getting shorter not
longer
> (thanks to Quanah's tireless efforts), the project can finally tackle some
> of
> the long-standing pain points. So this post aims to outline where we
> are/want to
> move to as well as to start a discussion and hopefully get you, the
> community,
> more involved on the road to 2.5 and beyond.
>
> We would love to welcome more people to participate in the project and make
> it
> more active and resilient. People of various skills and experience can make
> a
> difference, I am personally happy to assist anyone who wants to contribute
> with
> getting up to speed and start helping out, and for sure I'm not the only
> one.
> Also OpenLDAP is about more than just C programming and I'll try to outline
> the
> main areas where we want to focus our work in the short term here:
>
> One of the pain points in the 2.4 release cycle was the level of testing
> done on
> the code before we have released. There are issues with the existing test
> suite
> that make testing hard and I will come to how this could be tackled in a
> later
> email. In the short term however, we could benefit from having the tests we
> have
> run more often and on more diverse environments. If you have a chance to run
> it
> regularly, in a loop and report issues picked up, that would be a definite
> help.
> If you could help extend the test suite to cover scenarios that are of
> interest
> to you and are not appropriately covered yet, even better.
>
> 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).
>
> 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.
>
> This leads to documentation, much of which is already hosted on the
website.
> While I believe there is good work to be done on the admin guide, it is one
> of
> the better parts of our documentation. This is where user feedback on its
> usefulness is more important, please read it, have people on your team read
> it
> and show it people just getting started and report which parts are
> confusing,
> how they could be improved. We also intend to document our contributor
> guidelines in a more readable way.
>
> 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.
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.
>
> In general, moving to Gitlab should let us integrate CI much better,
> especially
> if there are people willing to integrate and manage external runners. As
> mentioned above, we could definitely do with more regular testing on
> non-Linux
> platforms, e.g. *BSD or Windows+MSYS2. Pull requests might then also be
> automatically tested.
Sounds good.
>
> 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.
> There are things we might not be able to influence easily (LDAP itself can
> be
> complex), but a fresh look might help direct efforts in the right
direction.
>
> 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.
Regards,
Ulrich
>
> Regards,
>
> --
> Ondřej Kuzník
> Senior Software Engineer
> Symas Corporation http://www.symas.com
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP