/!\ Looking for maintainers /!\

[lbdremy]

Hello,

I'm looking for people willing to maintain the module, i.e respond to issues, close issues, merge pull requests etc. The module has over 3500 downloads each month and it is growing, so you work will be used and appreciated for sure.

Thank you

[marc-portier]

ah, case of bad timing yes, I do want to keep my involvement and participate no, I haven't got time the last 4-5 months, and it probably will not get better for another 4 or so...

[ColadaFF]

Hi there, I would like to participate in this project. Tell me what I need to do for that.

[lbdremy]

Hello @ColadaFF,

Glad to hear that! It wouldl be nice to clean the issues by responding to people or by closing them if not relevant anymore. Also it would be nice to merge in all pull requests that seem good.

What do you think ? I'm gonna make you a collaborator on this project so you can work on it.

[ColadaFF]

Hello @lbdremy

I need to ask you something:

Could the test for the Node 0.8 version be removed ? Because that ones always fail in the last pull request - commits.

[lbdremy]

Sure, maybe we should add v0.12 and remove v0.8.

[ColadaFF]

Test on 0.12 are working great, but I think we should update some docs and features for Solr 5+

What do you think?

[lbdremy]

Sure the roadmap was something along those lines:

Roadmap

v0.3.x - v0.x.x

Test suite with mocha and chai instead of vows Implement all features available in Solr 4 (SolrCloud API in particular) (Now Solr 5 I supposed) Provide all low-level commands Complete documentation

v1.0.x

First stable version the API is frozen until v2.0.x, only new features and bug fixes can be introduced

So what you're suggesting is on the right track!

[luketaverne]

Hey, I've been using this project recently and found it really helpful! Thanks for writing it.

I'd like to help contribute/ maintain as well. Let me know if there is anything else you want done.

[lbdremy]

Thanks @luketaverne. Sure, you and @ColadaFF can collaborate to work this out. I'm gonna add as a contributor so you can close issues, merge pull requests, etc... if needed.

[nicolasembleton]

Just seeing that. Been using it a lot lately and making some updates. I could probably give a hand. Not sure to how much I can commit for now but I'll pay more attention to the issues and see if I can help there. (I will also open another ticket regarding some update I made I'd like to do a PR on)

[nicolasembleton]

Could we setup a Trello board to list the backlog and allow the users to vote on features too? That'd make it really easy to know what the users really want/need. (but would be redundant with GitHub issues, I agree). https://www.zenhub.io/ would be nice but users can't vote.

[lbdremy]

Hi @nicolasembleton, sure go head a Trello board can be a good idea.

I'm going to add you as a contributor so you can work on this repo.

[nicolasembleton]

If anyone wants to join and add features there: https://trello.com/b/xCBvFQSe/solr-client-board @ColadaFF @lbdremy @luketaverne I'll be adding features and things over time. We can then provide voting abilities.

[luketaverne]

I just made an account. Can you add me to the group or whatever? Seems like a better place to put feature requests. And I'll add what I'm working on to the list.

Thanks!

On Tue, Sep 1, 2015 at 11:05 AM, nicolasembleton [email protected] wrote:

If anyone wants to join and add features there: https://trello.com/b/xCBvFQSe/solr-client-board @ColadaFF https://github.com/ColadaFF @lbdremy https://github.com/lbdremy @luketaverne https://github.com/luketaverne I'll be adding features and things over time. We can then provide voting abilities.

— Reply to this email directly or view it on GitHub https://github.com/lbdremy/solr-node-client/issues/133#issuecomment-136641884 .

[nicolasembleton]

Yes sure. I've just added '@luketaverne' since I suppose it's you :) Thanks.

[nicolasembleton]

@lbdremy How can we push a new version to NPM? How would that work? We intend to release 0.6 this week (and clean-up the road-map towards 1.0 through a communication).

[lbdremy]

I suppose I can add you as a collaborator of the npm package so you can push the new version. I haven't followed the development during the last couple weeks, it seems that was really active, that's really cool :). When I publish a new version I try to add examples of the new features then I update the docs on gh-pages branch. I will work on the CONTRIBUTING.md tonight, I will add the command line to generate the docs.

Also I am wondering if you guys will be keen to adopt a commit guidelines ? I quite like the Angular.js commit guideline more than the one I use on this repo (NEW: subject [Verb imperative present tense + plus rest]) see https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#-git-commit-guidelines. It will allow to have a nicer and more readable commit history and we could generate a CHANGELOG from this history with this module https://www.npmjs.com/package/git-changelog for example.

[lbdremy]

By the way what is your npm username ? It seems your github username is not your npm username.

[nicolasembleton]

Noted. Thanks for the quick feedback. Sorry for NPM, I don't know why I had an account with nembleton but I've changed it to nicolasembleton to be more consistent. So you can use a similar one to github. Wrt the commit guidelines, I've seen your comment somewhere and I agree we should try to stick to that. Indeed makes the release note much easier. And yes, definitely adding documentation. It's one of my most important criteria. Adopting a library that doesn't have examples / doc is ever so hard / risky.

Also starting some discussions about style guideline, adopting jscs, semver, preparing 1.0, etc. Btw, do you have a Trello username/email? I'll add you to the board. It starts to have some life into it.

[lbdremy]

No worries, you are now a collaborator of the solr-client module on npm. :) Sure about the style guideline, jscs, semver you can open a issue and we can discuss.

Generally when I contribute to a module I tend to stick with the style of the codebase to keep the codebase consistent since the style does not really matter to me until it is consistent. I like semver, it is quite simple and easy to understand and thus to work with it: (BREAKING_ CHANGE).(NEW_FEATURE).(BUG_FIX).

[nicolasembleton]

Thanks. All good. Will work on preparing 0.6 (and further) and start the convos on GitHub for the other topics.

[kibertoad]

@lbdremy Do you still need people for the project?

[lbdremy]

Hi @kibertoad , Sure always looking for maintainers, there is no maintainer really active at the moment.

[kibertoad]

@lbdremy Awesome! I'm wrapping up the majority of things I wanted to do with knex in the nearby future, and wouldn't mind working on another OSS Node project after that. Things I've been thinking about:

1. Migration from Travis to GitHub Actions (Travis was slow for quite a while, and their support for OSS is steadily dwindling);
2. Migration from request (deprecated) into undici (fastest HTTP client in town);
3. Docker-based solr testing;
4. TypeScript types;
5. Prettier integration;
6. ESLint integration;
7. Replacing Bluebird with native Promises.

Is there a list of things you wanted to do but never got around to?

[julianlam]

request being deprecated doesn't mean it isn't maintained, it just means it's feature complete. I don't actually know if there are security vulnerabilities, but I imagine if there were I would've heard about them.

Additionally, I can't imagine request would have a bottleneck larger than the http request itself :thinking:

[kibertoad]

@julianlam request's maintainer explicitly encouraged people to move on and stop using request:

 What’s the value in a version of request that is incompatible with the old patterns yet not fully embracing the new ones? What’s the point in being partially compatible when there’s a whole world of new modules, written by new developers, that are re-thinking these problems with these patterns in mind?

The best thing for these new modules is for request to slowly fade away, eventually becoming just another memory of that legacy stack. Taking the position request has now and leveraging it for a bigger share of the next generation of developers would be a disservice to those developers as it would drive them away from better modules that don’t have the burden of request’s history.

(https://github.com/request/request/issues/3142)

undici literally has three times the throughtput of Node http-based client. Check the benchmark: https://github.com/nodejs/undici And having that in mind, why settle for something less performant, if it's possible to use the best-in-class solution?..

[julianlam]

@kibertoad You definitely can :smile: honestly I haven't been doing much as maintainer at all, so you're offering much more than I ever have :wink:

That said, I still use request-promise-native, which gets around the "old patterns" issue.

[kibertoad]

So if there are no objections, I can start with GitHub Actions migration and Docker-based tests, that will speed up iteration for remaining items. What's the main communication channel for discussing changes? Should I use gitter or something else?

[lbdremy]

Your plan looks good @kibertoad , I have added as contributor on this repo and on npm for the package solr-client.

For the test suite, there is a section here https://github.com/lbdremy/solr-node-client#test, with info to run the test suite. On travis a Solr instance is setup before the test suite is run , see https://github.com/lbdremy/solr-node-client/blob/master/.travis.yml.

Regarding the roadmap it was left like that https://github.com/lbdremy/solr-node-client#roadmap but it's quite old. Still I think we need to go 1.0.0 on the next big release (still no semantic versioning before 1.0.0, even if we offer migration guides in the README).

Really interesting this new HTTP client from Nodejs core team, I don't mind using this new client, and I don't think it will involve breaking changes in the solr-client API, everything will be underneath the API layer.

[kibertoad]

@lbdremy Thanks! Trying to run tests on Docker solr image, no success so far. Does solr-node-client only support up to Solr 4.x? The oldest Docker image is for 5.x.