[Bro-Dev] CBAN design proposal

[Vlad Grigorescu]

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 <robin at icir.org> 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 * robin at icir.org * www.icir.org/robin
> _______________________________________________
> bro-dev mailing list
> bro-dev at bro.org
> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.icsi.berkeley.edu/pipermail/bro-dev/attachments/20160523/b9d28063/attachment.html