[collectd] RFC: Should we maintain plugins written in Go?

[Florian Forster]

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