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,