On 02.03.20 06:55, Emil Madsen wrote: > > My original goal for the PR, and the following fork was indeed backwards > compatibility. I created the PR with the goal of merging our in-house nagios > plugin with the Prometheus one, as I though the resources spent on > maintaining it, might as well be shared, and benefit multiple people. > > No reason to reinvent and remaintain the development of the wheel. > > I don't have a lot of input with regards to the status of the current > repository, > and whether it belongs in the Prometheus github organization, although it > does seem a bit like a misfit. > > What I have a bit of input about, is my role as a potential future maintainer. > The way I see it, I was gonna have to maintain this script in-house anyway, > so the maintenance burden is one I already have. I do not feel strongly > about whether it'll be maintained in the promtheus github organization, in > the prometheus community, or where it already is.
Great. Thanks, Emil. Which opens up three possibilities: 1. Make Emil the maintainer of the current prometheus/nagios_plugins repository, where he can then merge in his current work in a way that doesn't break backwards compatibility. 2. Create a Nagios plugin repo in prometheus-community and make Emil the maintainer of it. 3. Leave Emil's fork where it is now and point to it from prometheus/nagios_plugins and from prometheus.io Option 2 and 3 come with the additional decision for how long we want to keep the old prometheus/nagios_plugins repo around. That's also the only thing I feel strongly about: Let's not remove the existing repo anytime soon. I suspect there are a lot of silent users of it, including usage patterns like downloading the script directly from GH upon provisioning of a machine and such. (I guess GH move redirection can help here, but then we really should be 100% backwards compatible, which is planned anyway, but might turn out to be a burden.) The feedback so far seems to gravitate towards option 2. But my expectation is that that's the option with the most friction. Either 1 or 3 seems to create less changes. (But I'm also biased because I'm generally happy to have maintainers in the Prometheus GH org that are not (yet) team members, and I am not a huge fan of prometheus-community in general). Now that we have Emil's statement of commitment, could each of you who has an opinion about it let me know what you think (again)? I will leave this open for a couple of days and then implement the solution that receives the best vibes. (If you feel strongly about any of the solutions and you want to veto anything, it would also be a good time to let me know.) Cheers everyone. -- Björn Rabenstein [PGP-ID] 0x851C3DA17D748D03 [email] [email protected] -- You received this message because you are subscribed to the Google Groups "Prometheus Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/20200304184523.GQ14683%40jahnn.
