Hand this repository over to a new maintainer

[saj]

This plugin was first written in 2012 and tested against early 0.x releases of ElasticSearch. I moved on to other things. I suspect @olorin moved on to other things. I have not touched ES in years and am no longer in a position to adequately vet feedback. Recent PR and Issue activity would suggest that some folks still find some use in this plugin. (Have you met our lord and savior?)

It is unfair to serve this repository without also taking the time to review and incorporate patches from users. Forks are disruptive. Rather than take the repo offline, I would prefer to hand it over to someone who cares. A transfer should retain all open PRs and Issues on the repo.

Please post a message below if you would like to volunteer as a maintainer. You should meet the following general requirements (lest we again end up in this pickle):

• Accept the terms under which this work is licenced. (MIT Expat IIRC.)
• Know stuff about ElasticSearch. You must understand ES failure modes. You should be in a position to test patches to this plugin against new ES stable releases in throwaway clusters with varying configurations (e.g.: single-node, many-node). Bonus points if you are able to regression test against older ES stable releases to ensure backwards compatibility is retained.
• Know stuff about Nagios.
• Have at least a passing familiarity with Python.

It would probably be wise to transfer ownership to a GitHub Org rather than to any one individual.

Cheers!

[kwisatz]

Hi, we (@tentwentyfour) would be interested in contributing. We don't necessary want to take over maintership, especially since we do not entirely fulfill the requirements outlined above, but we might have more PRs than the current and we really like installing the module through pip and official channels…

[saj]

Thanks for your interest. The package on PyPI happens to be owned by an ex-Anchorite. We may be able to arrange for the PyPI package to be handed over together with this GitHub repo. I would need to speak with the current PyPI package owner; handover of that package would be contingent on their approval.

(@anchor tend not to use the public PyPI to distribute our internal Python libraries, hence the mismatch in ownership.)

[olorin]

We may be able to arrange for the PyPI package to be handed over together with this GitHub repo. I would need to speak with the current PyPI package owner; handover of that package would be contingent on their approval.

I'd be more than happy to hand over the pypi package to someone who's willing and able to maintain it; as @saj guessed I've also moved on to other things and lack the requisite recent experience in Elasticsearch.

[tomsommer]

Could you please, at least for now, allow access to someone who can approve some of the pull requests, this plugin is useless with ES 5 atm.

[saj]

Approve how? What are you asking for? Someone to blindly click the Merge button on every new pull request? There are dozens of people who can already do that. They don't because they know better. What happens when one or more of those unreviewed and partially-tested patches breaks someone who builds off of head?

You state that master is currently useless with ES 5. If this is true (and I imagine that you are right), this would at least be an unyielding truth on which users could depend. This plugin does not work with ES 5. Don't even try. There is value in that. User expectations would change the moment that unreviewed patches were accepted. So long as this bug remains open, I think it would be preferable for master to be in a state where it is known to be incompatible with ES N (for some value of N) rather than knowingly degrade into unpredictable states of brokenness depending on the day of the week because there is no QC. Cowboy shenanigans will erode all trust in the origin fork, further negating its need to exist. At least what we have now is known to work reliably with (very?) old ES releases. That may not be of much practical value to you, or to anyone else in 2017, but I think the alternative would be an unforgivable position to take with software that may be deployed into a production setting.

To put it another way, how would blind merging be any different to you forking and cherry-picking the patches you need to solve your immediate problem? If your circumstances permit a relaxing of reliability requirements, fork and do as you please.

[tomsommer]

What an attitude.

There are tested fixes pending, just because you refuse to test them, does not mean they have not been tested or do not work.

This is a prime example of how projects become stale and useless on Github. Sure, people could fork, but that's a non-optimal solution, as this project is the first choice for many looking for a ElasticSearch Nagios plugin (Google etc.).

At least state in your README that this check plugin is for ElasticSearch 2.X and nothing newer, if your ambitions are not bigger than that.

To anyone visiting this project, looking for one that works with ES 5.0, try https://github.com/orthecreedence/check_elasticsearch

[ctd]

To put it another way, the reason @anchor won't merge new PRs is because we aren't in a position to take ownership of testing the resulting code to a standard that we are satisfied with publishing.

Although @tomsommer states there are tested/working patches pending, it would be naive for us to merge without performing our own testing. We don't have an interest in doing this now. It would also create a false impression that the repository is being maintained.

For that reason, we'd rather leave this repository in an unmaintained state, available for adoption to someone who is willing to completely maintain it, than to haphazardly maintain it.

[mathewmeconry]

Maybe it would be a good approach to write down the tests which have been performed during the active development and then to configure Travis (It's free for open source projects) to perform the tests against a single node cluster and multi node cluster with a lot of different versions. I know it's a lot of work to configure travis to do that but afterwards nobody needs to setup a throw away cluster.
I could assist in configuring travis

[ctd]

@mathewmeconry CI is certainly a good idea, and thanks for the offer of help, but it isn't a replacement for having a maintainer who is actually interested in maintaining the project.

[mathewmeconry]

@ctd I thought it could help reduce the workload and I think it easier to find somebody who maintains it if he/she doesn't need to test against each version manually

[ctd]

@mathewmeconry you're right - but it's just not work that @anchor will commit to, so the codebase will still need a new maintainer first.