Please drop support for Mozilla's ldapsdk

[389-ds-bot]

Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/50302

• Created at 2019-03-25 12:16:13 by hmc
• Closed at 2019-05-27 15:01:13 as fixed
• Assigned to mhonek (@kenoh)

---

As noted in PR 50295, Mozilla's ldapsk is no longer in development. This means supporting the library in future will become more difficult for various reasons, including security, general availability as a package in distributions and lack of pkg-config files.

Please drop support for ldapsdk.

[389-ds-bot]

Comment from mhonek (@kenoh) at 2019-04-04 17:50:14

Metadata Update from @kenoh:

• Issue assigned to kenoh

[389-ds-bot]

Comment from mhonek (@kenoh) at 2019-04-04 17:50:37

Metadata Update from @kenoh:

• Custom field origin adjusted to None
• Custom field reviewstatus adjusted to None
• Issue set to the milestone: 1.4.1

[389-ds-bot]

Comment from firstyear (@Firstyear) at 2019-04-16 06:01:29

#3391

[389-ds-bot]

Comment from lslebodn at 2019-04-16 09:27:02

Just a note that openldap does not provide pkg-config files either.
Other reasons are reasonable and valid.
+1

[389-ds-bot]

Comment from hmc at 2019-04-16 14:30:22

@lslebodn That's no problem. I've already sent patches to the openldap project adding support for generating pkg-config files at compile-time.

[389-ds-bot]

Comment from mhonek (@kenoh) at 2019-04-17 14:54:59

@Firstyear I am not sure why you produced the PR 50332 without asking me as an assignee about the status in the first place. Could have saved some effort...

Anyway, there is much more to be removed, I presume. Actually, I've had a patch for 49730 (almost identical issue, I'd say) sitting around for a while (mea culpa) with a bunch of other related changes, for which I now filed PR 50334.

[389-ds-bot]

Comment from lkrispen (@elkris) at 2019-04-17 16:42:10

I agree with Matus, there is more work to do and the PR 50334 looks more complete

[389-ds-bot]

Comment from firstyear (@Firstyear) at 2019-04-18 02:03:33

@kenoh Well, 50334 wasn't submitted when I started to look at this, so I'm happy to defer to your change. I think you'll find that assignments are like an expression of interest, where some of the date back to years, and no work is done - IE they don't really mean much. I have had tickets assigned to me that other people have then worked on, and submitted solutions for. We are a team and if someone else does work in the teams interest we should be happy.

[389-ds-bot]

Comment from mhonek (@kenoh) at 2019-04-18 09:39:37

@Firstyear So, again, as I said, the reason is not to double the work efforts. Mere "Hey, what's your status? Do you mind if I make a patch?" is much faster than producing the actual working and tested solution; in the meantime, one can defer to other work. And for an interest there are bookmarks; being an assignee should mean some responsibility, otherwise we could just rename it to "Interested". If one is unsure about a progress on some ticket, just ask, if timed out then bring team to attention. Unless we start clock-in/clock-out, the assignee should mean something.

We are a team and if someone else does work in the teams interest we should be happy.

True, and I am happy for all your work. However, for example, you can produce fixes for areas I would struggle with much much longer; at the end of the day, given your experience, time spent there would be much more beneficial to the team and product itself.

[389-ds-bot]

Comment from firstyear (@Firstyear) at 2019-04-18 12:16:06

@kenoh Historically the team has been very bad at communication (and interests) outside of Red Hat. So I think we will keep having these communication and teething issues while communication and priorities aren't upstream. Next time I'll ask on the 389-devel list in that case (because this was my mistake), but we also need to stop assigning work unless we are actively working on it too (which everyone does/has done, I think I have 50+ issues assigned ...), and we all need to pay attention to that mailing list and topics :) . Is that reasonable? Should we also go through and "release" all our assigned issues unless we are working on them in that case? (Perhaps this topic is better on mailing list ...)

Also I'm not sure about that last comment, but I appreciate your faith in me :)

[389-ds-bot]

Comment from mhonek (@kenoh) at 2019-05-27 15:01:14

Closing as fixed. For a summary, PR 50332 had been dropped in favour of now merged 50334 (b770ac7) which in turn was completed by PR 50382 (08a6aad).

[389-ds-bot]

Comment from mhonek (@kenoh) at 2019-05-27 15:01:14

Metadata Update from @kenoh:

• Issue close_status updated to: fixed
• Issue status updated to: Closed (was: Open)