Good discussion, thanks for kicking this off. > The first two require involvement from someone on the team, mostly for > reviews. Once reviewed, I'd consider to give commit access *for that > repository* to the contributor, so they can maintain their plugin > unilaterally, i.e. without further code reviews. I assume you are referring this with respect to exec plugins. If so, yes this would be great. Our team was looking for a place that can hose multiple scripts for exec plugin purposes and this would help us surely. Instead of current out-of-tree approach, this would help consolidate the scripts. Once created, would these be independent of Collectd release or would they be part of release cycle?
> * Improve discoverability of plugins. Could you shed some light on how you meant to appraoch this? Discoverability so that new plugin authors could reuse available plugins or is it more about discoverability of what plugins provide? > On the other hand, curating a list of exec plugins is likely much less work > and might also help users Agree, this should be light weight for maintainers as the processes are in place Thanks, Sunku Ranganath -----Original Message----- From: collectd <collectd-boun...@verplant.org> On Behalf Of Florian Forster Sent: Monday, April 27, 2020 10:34 AM To: Matthias Runge <mru...@matthias-runge.de> Cc: collectd@verplant.org Subject: Re: [collectd] RFC: Should we maintain plugins written in Go? Hi Matthias, On 2020-04-27 10:08, Matthias Runge wrote: > While I also like the idea to provide a "repository" for exec plugins, > or a list of exec plugins, I wonder if we would like to add any > limitations? Would we "support" an exec plugin written in scheme? What > would it mean, if a plugin is included in the repository. Would we > care about it? Would we fix a bug, a CVE? all excellent questions. My goals would be: * Review the naming schema of metrics. This is something that new plugin authors often get wrong. * Establish best practices, such as "script requiring root privileges sudo's itself if necessary". * Improve discoverability of plugins. * Provide a CI/CD pipeline and possibly a release process, so that individual plugin authors don't need to. The first two require involvement from someone on the team, mostly for reviews. Once reviewed, I'd consider to give commit access *for that repository* to the contributor, so they can maintain their plugin unilaterally, i.e. without further code reviews. The last point (CI/CD piperline) is arguably the most language-dependent and work intensive. I guess it would be reasonable to draw a line somewhere, though I'm not sure where it would be. That said, most plugins I've seen in the wild didn't use "unusual" languages – they were mostly in Bash, Python, and Ruby. On the other hand, curating a list of exec plugins is likely much less work and might also help users. For reference, a (very imcomplete) list is here: https://collectd.org/wiki/index.php/Category:Exec_Plugins Best regards, —octo -- collectd – The system statistics collection daemon Website: http://collectd.org GitHub: https://github.com/collectd Twitter: http://twitter.com/collectd _______________________________________________ collectd mailing list collectd@verplant.org https://mailman.verplant.org/listinfo/collectd _______________________________________________ collectd mailing list collectd@verplant.org https://mailman.verplant.org/listinfo/collectd