On Wed, 4 Mar 2020 at 18:45, Bjoern Rabenstein <[email protected]> wrote:
> 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.) > I'd tend towards 3, we can have github auto-redirect. In any case it's easy to repoint things on the exporters page. -- Brian Brazil www.robustperception.io -- 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/CAHJKeLrhyej1OJ%2BKKkmkPact77LUgtbO60uLp4%2BOaZ3ydyhtFQ%40mail.gmail.com.
