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

Reply via email to