[Pdns-users] Status of the LDAP backend in 3.0 release

[Nick Milas]

> I wanted to quickly chime in on this. I agree with the decision to 
> move the LDAP backend into "unmaintained" status and not fix these 
> bugs right now. If there isn't a big enough community demand to supply 
> the resources needed to maintain it, then there likely isn't a big 
> enough demand to make it worthwhile anyway.
>
I feel I should repeat here Udo Rader's very thoughtful comment that: 
"...(it) might just be that not all people interested in the LDAP 
backend are actively following the mailing list"! In fact, it seems that 
there are quite some people and organizations using it, and moving into 
"unmaintained status" (I'll call it UMS) would be harmful to them. 
However, since little interest has been explicitly exhibited, entering 
UMS might ring a bell to some of the users/organizations to engage more 
actively in its development (but it could push them to entirely drop 
LDAP backend too!). But, of course, there is also Udo's offer to 
possibly "offer some manpower", and, hopefully, LDAP backend might avoid 
entering UMS after all (I hope we will hear some news from him some time 
soon, after "having a look at the issues") by catching up with v3.0. :-)


> *However*, I do not think marking the bugs "will not fix" is the right 
> move, as I believe there is a better alternative. Where I work, we 
> have another status called "Deferred." When a bug is determined to be 
> legitimate and needs to be fixed, but for some reason or another can't 
> be fixed right now (e.g., not enough resources, requires major 
> restructure somewhere that needs serious discussion, etc.), we mark it 
> as "Deferred." This indicates later down the road that we had already 
> decided to fix it, but couldn't at that time.
>
> I think having a status similar to "Deferred" for PDNS bugs and 
> putting these bugs in that status would be a better thing to do. A 
> project this large can have a lot of "Won't Fix" bugs, and a year down 
> the road it could be very hard to sort the "Can't fix" bugs out from 
> the "Won't fix" bugs.
>
>
This might be a useful policy; filtering tickets by "Deferred" status 
sounds efficient and helpful (if developers concerned agree too!). On 
the negative side, the existence of a "Deferred" status might 
(psychologically) encourage a more frequent "defer" of issues. :-(

Nick