<div dir="ltr"><div>I think we&#39;re generally on the same page, but I wanted to elaborate a bit on what I envisioned with the plugin submission process.</div><div><br></div><div>When a contributor submits a new script, there would be some mandatory checks that would need to pass for the script to be included:</div><div><br></div><div>* Is the plugin structure valid?</div><div>* 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&#39;s possible that we wouldn&#39;t even need the license if the submission process puts a default license on any plugin that doesn&#39;t specify otherwise.</div><div>* If there are dependencies, are those already in the CBAN repository?</div><div>* Is Bro able to load this plugin with --parse-only, or does it generate a parse error?</div><div>* Is there already a plugin with that name and version number? If so, the author would need to increment the version.</div><div><br></div><div>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.</div><div><br></div><div>Once a plugin has been submitted, if it passes those checks, I think it should be automatically pulled into a repo. I don&#39;t think that we need manual intervention for this. At this point, though, I think we could run some &quot;quality tests&quot; and give the plugin a quality score. This might be things like:</div><div><br></div><div>* Is there documentation? (Both a README and checking to see if, for example, external redef-able consts are documented).</div><div>* Are there btests?</div><div>* Do the tests pass?</div><div>* Does the plugin load in bare mode?</div><div><br></div><div>These quality scores would be strictly informative, and wouldn&#39;t prevent or modify the acceptance of the plugin.</div><div><br></div><div>What I&#39;m imagining is something like this: <a href="https://forge.puppet.com/vshn/gitlab/scores#module-release-info">https://forge.puppet.com/vshn/gitlab/scores#module-release-info</a></div><div><br></div><div>  --Vlad</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 23, 2016 at 10:16 AM, Robin Sommer <span dir="ltr">&lt;<a href="mailto:robin@icir.org" target="_blank">robin@icir.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On Sat, May 21, 2016 at 23:16 +0000, you wrote:<br>
<br>
&gt; I think there is a broad spectrum from no interaction to vetting and<br>
&gt; pulling into the main repository. It is about finding the right<br>
&gt; balance.<br>
<br>
</span>Yep, and I&#39;m arguing for going very far towards the &quot;no interaction&quot;<br>
side, with just some automatic checks for the most crucial things.<br>
Maybe the initial pull request for integration could be merged<br>
manually to avoid any spamming, but any updates for example should not<br>
require any interaction from us.<br>
<span class=""><br>
&gt; I do think there is another level of non blocking checks and quality<br>
&gt; control we can provide.<br>
<br>
</span>Yes, indeed, I like this. With things already merged in, we can in<br>
parallel, in the background, build up a toolbox of things to check for<br>
and mark a module accordingly.<br>
<span class="im HOEnZb"><br>
Robin<br>
<br>
--<br>
Robin Sommer * ICSI/LBNL * <a href="mailto:robin@icir.org">robin@icir.org</a> * <a href="http://www.icir.org/robin" rel="noreferrer" target="_blank">www.icir.org/robin</a><br>
</span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
bro-dev mailing list<br>
<a href="mailto:bro-dev@bro.org">bro-dev@bro.org</a><br>
<a href="http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev" rel="noreferrer" target="_blank">http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev</a><br>
</div></div></blockquote></div><br></div>