I think we're generally on the same page, but I wanted to elaborate a bit on what I envisioned with the plugin submission process.
When a contributor submits a new script, there would be some mandatory checks that would need to pass for the script to be included: * Is the plugin structure valid? * Is there a valid metadata file? This file could list things like dependencies, what version of Bro the plugin works on, etc. I think the bare minimum of what needs to be in the plugin is: 1) version number and 2) license information. It's possible that we wouldn't even need the license if the submission process puts a default license on any plugin that doesn't specify otherwise. * If there are dependencies, are those already in the CBAN repository? * Is Bro able to load this plugin with --parse-only, or does it generate a parse error? * Is there already a plugin with that name and version number? If so, the author would need to increment the version. I think this is a nice balance between some bare minimum checks designed to ensure that the plugin is actually installable and not putting too much of a burden on contributors. Once a plugin has been submitted, if it passes those checks, I think it should be automatically pulled into a repo. I don't think that we need manual intervention for this. At this point, though, I think we could run some "quality tests" and give the plugin a quality score. This might be things like: * Is there documentation? (Both a README and checking to see if, for example, external redef-able consts are documented). * Are there btests? * Do the tests pass? * Does the plugin load in bare mode? These quality scores would be strictly informative, and wouldn't prevent or modify the acceptance of the plugin. What I'm imagining is something like this: https://forge.puppet.com/vshn/gitlab/scores#module-release-info --Vlad On Mon, May 23, 2016 at 10:16 AM, Robin Sommer <[email protected]> wrote: > > > On Sat, May 21, 2016 at 23:16 +0000, you wrote: > > > I think there is a broad spectrum from no interaction to vetting and > > pulling into the main repository. It is about finding the right > > balance. > > Yep, and I'm arguing for going very far towards the "no interaction" > side, with just some automatic checks for the most crucial things. > Maybe the initial pull request for integration could be merged > manually to avoid any spamming, but any updates for example should not > require any interaction from us. > > > I do think there is another level of non blocking checks and quality > > control we can provide. > > Yes, indeed, I like this. With things already merged in, we can in > parallel, in the background, build up a toolbox of things to check for > and mark a module accordingly. > > Robin > > -- > Robin Sommer * ICSI/LBNL * [email protected] * www.icir.org/robin > _______________________________________________ > bro-dev mailing list > [email protected] > http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev >
_______________________________________________ bro-dev mailing list [email protected] http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
