[Bro-Dev] CBAN design proposal

Aashish Sharma asharma at lbl.gov
Sat May 21 15:52:00 PDT 2016


> In other words, my proposal is to put authors into control of their
> code, and make them fully responsible for it too --- not us. We'd just
> connect authors with users, with as little friction as possible.
> 

I support this completely. 

> If we want some kind of quality measure, we could introduce stars for
> modules that user assign if they like something; or even some facility
> to leave comments or other feedback that's visible to everybody. We

I think community vetting and feedback (and experience stories) is the right way to go here. 

Bro team vetting something will be very hard. My personal experience says there are times when scripts bring surprises weeks and months down the line - so testing isn't merely run a few days and give an OK.

Aashish 


On Sat, May 21, 2016 at 03:44:01PM -0700, Robin Sommer wrote:
> 
> 
> On Fri, May 20, 2016 at 20:16 +0000, Jon wrote:
> 
> > Here’s an updated design doc for CBAN, a plugin manager for Bro, with
> > some new ideas on how it could work:
> 
> Cool, thanks. I'm going to send some feedback but first I wanted to
> bring something up that might be controversial. :-)
> 
> As I read through the design doc, I started questioning our plan of
> curating CBAN content. I know that's what we've been intending to do,
> but is that really the best approach? I don't know of script
> repositories for other languages that enforce quality control on
> submissions beyond checking technical conventions like certain meta
> data being there.
> 
> I'm getting concerned that we're creating an unncessary bottleneck by
> imposing the Bro Team into the critical path for submissions and
> updates. Why not let people control their stuff themselves? They'd
> register things with CBAN to make it available to everybody, but we'd
> stay out of the loop for anything further. We may still want to keep a
> local copy of the code to protect against stuff going offline, but
> that could be automated. Or we could even move that burden to the
> authors as well and just keep a reference where to find the code,
> without a local copy; if it disappears, so be it.
> 
> In other words, my proposal is to put authors into control of their
> code, and make them fully responsible for it too --- not us. We'd just
> connect authors with users, with as little friction as possible.
> 
> If we want some kind of quality measure, we could introduce stars for
> modules that user assign if they like something; or even some facility
> to leave comments or other feedback that's visible to everybody. We
> could also verify if a plugins builds and loads correctly, or if tests
> pass. But we wouldn't block it if something fails, just mark it (say,
> with a banner saying "tests pass", "tests fail", "no tests").
> 
> Thoughts?
> 
> 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


More information about the bro-dev mailing list