-
Notifications
You must be signed in to change notification settings - Fork 63
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
Hand this repository over to a new maintainer #48
Comments
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… |
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.) |
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. |
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. |
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 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. |
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 |
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. |
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. |
@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. |
@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 |
@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. |
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):
It would probably be wise to transfer ownership to a GitHub Org rather than to any one individual.
Cheers!
The text was updated successfully, but these errors were encountered: