Hi, I've prepared a plan what the project wants to achieve as part of the 2.5 stream apart from core OpenLDAP development that I intend to send to -technical for wider discussion and as a call for participation.
It has been suggested to me that people might want to comment/propose changes to it so attaching a draft here. Please let me know what you think or if you agree in broad terms it is fit to be circulated more widely. Thanks, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
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 to get up to speed and be able to do so, 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 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. 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. 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 host a wiki, which means yet another piece of software to manage and maintain, or a static webpage site based on GitLab pages. My preference is the latter, it is no harder to edit than a wiki, gives us more freedom and we wouldn't have to maintain another user base. 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? 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. Regards,