-
Notifications
You must be signed in to change notification settings - Fork 145
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ldapjs] Consider for maintenance #221
Comments
This does indeed look like a good candidate I would not be surprised if several large enterprises were unknowingly dependent on this unsupported package. |
We need to focus also on this type of issue: when a package needs a new "incubator" to start a new life.
Relates to #144 |
🤦♂️ I got contacted this afternoon by my old employer because an app that has been running flawlessly for the year since I left suddenly stopped working. The issue was they updated Node to v10 and the ldapjs library, the hinge of the app, was causing a TCP connection reset. |
I propose we ask if we could ask for a transfer of the package to this group. This should include both the github repo (for issues and PRs) and the ownership of the npm package, and start working on it.
Wdyt? |
I think that for whomever volunteers to take this project on that it would be a waste of their time working on a fork that might never take over I really wish I could be one of the volunteers on this specific project. But, as you know from Fastify and Pino, @mcollina, I just don't have the capacity. The best I can offer is an advisory role. I don't personally need the ldapjs module any longer. But I do still provide maintenance to https://www.npmjs.com/package/activedirectory2 which relies upon ldapjs (and gets a surprising amount of usage). |
There is a way to take ownership of a unmaintained module on npm, I've done this several times in the past, and it works reasonably well (npm support is amazing). Even if Joyent does not respond to transfer the module, it's possible to help the community anyway. |
Then your plan sounds fine to me. |
Hey all, I brought up transferring the |
He didn’t really fork it though. He started from scratch in TS and has only implemented some portion of the client. |
@mcollina I don't think this repo is necessarily the right place to transfer modules. I think this group should help to find volunteers who want to help in situations like this but not necessarily own the modules as I'm worried that will set an expectation that may not be able to be met. So the first step is to identify the volunteers who want to take ownership/move this forward. At that point we can then figure out what the best org/place for the module might be. |
@melloc I can help with getting some PRs approved, pushing out some new npms, and getting the project to work with latest node versions. That said, I would appreciate someone else taking over the project at some point, as I have moved my projects to use ldapts. I would also be willing to merge the projects, too. The main differences at this point are:
|
We have not finalized all of our WG details on this, but I agree fully with this statement. We should not directly be taking over projects yet (ever?). We should focus on being facilitators, as that is a method which we can scale up for the time being. |
@melloc I created https://github.com/ldapjs . Feel free to transfer the repo(s) there. I can't promise to be able to work on this much more than it is already being worked on, but I can get some movement going. If you need anyone to vouch for me I am certain @mcollina would be willing. |
I'm not sure what the state of this working group is, but I have another query about this topic. Does the WG think it would like to help with maintaining project domain names? At the moment, we have the ldapjs project under management by a very small community, but Joyent still retains the domain name Relevant ldapjs issue: ldapjs/node-ldapjs#679 |
My first thought is that I don't think this group will manage DNS entries for projects, but the team can discuss. If the project was a member of the OpenJS foundation, they would potentially help on that front. |
Okay. FWIW, if this group intends to ease the burden of keeping unmaintained "core" modules up-to-date, these sorts of things will come along with it. I believe this issue is showing a concrete example. The module, As I mention in the issue I linked in my last post, I think the domain should just go away completely and the project fully shift to using the |
In this case, the project isn’t owned by individuals, but by a corporation, so details around IP like domain names will be significantly more complex. |
No, it was transferred to the community and is maintained by myself and another individual. |
Ah, the OP says you’re in no way affiliated with it :-) In that case, hopefully joyent holding on to the domain is an oversight, and would transfer it to the two of you - at which point, one possibility is applying to join the Open JS Foundation, who would hold and pay for the domain as needed. |
I'm closing this due to lack of movement. I think there are unanswered questions remaining, in particular it's still not clear to me what this WG actually provides, or intends to provide, to modules that are in the state ldapjs was in before it was transferred to me, nor what it provides to modules that are in ldapjs's current state (a large project with ongoing maintenance burden being maintained by one person who has zero use for the module), but it's clear it isn't anything in this issue. |
I think there was a time where we had ambitions to help provide tooling to make it easier for maintainers of large and important projects. It became pretty clear that the group did not have the time/energy to really well support those things. Mostly I think the group has spun off a bunch of other smaller scoped projects and the WG is in place still mostly to steward those. For requests like this, I think where things really fell apart was that we didn't have the resources to even achieve movement on the critical projects we picked, so picking up more things from other less critical ones was clearly not going to work. Sorry this was all unclear, maybe we should update the readme to try and reflect the current state a bit better? |
Yes, the readme should be synchronized with the current goal of the project. I did consult it, and linked resources, to try once again to understand this project's purpose before closing this issue. |
https://github.com/joyent/node-ldapjs
Note: I am in no way affiliated with the package in question.
I'd like to suggest the ldapjs package for inclusion in the maintenance program. According to the public stats on npmjs.com:
Anecdotally, I think you'd have a very hard time finding another package that fills the role this one does within the Node community. Chances are, if you need to interact with an LDAP server via Node then you'll have this package somewhere within your dependency tree.
This package seems to be abandoned. It was originally authored by @mcavage, then maintained by @pfmooney, and most recently seems to be under control by @melloc. At this point the package has months old outstanding fundamental issues:
PRs with popular backing are ignored:
I'm not sure if this issue is the right format, but @mcollina suggested I bring it here (https://twitter.com/matteocollina/status/1139655792997650434). I looked through the issues around suggesting packages and didn't see anything about a formal process.
Again, I'm not affiliated with this module. I just recognize that it fills a big role for the segment of the community it serves, and that it is time for some TLC be given to it. From the evidence presented here, I think it is a waste of time to try and wake the project up with its current leadership.
The text was updated successfully, but these errors were encountered: