I've gone through and looked at all of the open issues that were in the OpenLDAP product queue. The end result of this is that numerous duplicate issues, invalid issues, and issues where we never got any response after asking for more information have been closed out appropriately.
As a part of this I've gone through and marked many of the bugs with target milestones and sometimes keywords.
Any issues with a target milestone of 2.5.0 and a keyword of OL_2_5_REQ is an item that should likely be fixed for OpenLDAP 2.5. If it is not going to be fixed for 2.5, then we need to come to a decision on what release series we plan on fixing it in. I.e., I generally consider these high priority items. Often these are things we've put off doing for 2.4 due to disruption/incompatible API changes, etc, but are generally necessary for the overall improvement of OpenLDAP. A number of these issues already have patches. Some of them are documentation items that are likely not too hard to deal with, and I've self-assigned many of those. There are a total of 175 items in this list:
Any issues with a target milestone of 2.5.0 but no keyword of OL_2_5_REQ are items that need further review by other team members. I put items in this category that seem of general interest, but may be more appropriate for a later release, or perhaps remain unscheduled at this time. There are 188 issues in this list:
There is one open issue with the 2.4.50 milestone that I'll be taking care of.
All other issues I've left unassigned. This does not mean they have no value, but they do not seem critical for the OpenLDAP 2.4.50 or 2.5 releases and can be re-examined at a later time.
All of this should help anyone who has expressed a desire in the past to work with the project -- There is now a well sorted set of issues that need addressing. Some of these items are fairly straight forward, especially documentation updates. Feel free to sign up to gitlab, fork the repo, and submit merge requests for issues to be reviewed. Please add any merge request links to the related issue in the tracker as well.
Overall, given the list of items in the first category, I'm not sure the 2.5-odd/even track is the best route. I'm personally leaning more towards 2.5, 2.6, 2.7, etc, where each of these releases is of a short duration. There seems to be enough work at this time to support more frequent minor version releases and that would allow us to sucessively improve the product. Having defined sets of issues for given target release milestones should help significantly as far as planning and resource allocation is concerned.
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
This is fantastic, and I really appreciate you doing the work. Having everything categorized and milestoned is a major improvement.
I'm a fan of smaller and more frequent releases in general so I'm happy to hear that suggestion. Gets changes out to users sooner, but also reduces the urge to delay a release rather than defer features, or sneak risky changes into point updates.
-
Quanah Gibson-Mount -
Ryan Tandy