[Bro-Dev] CBAN design proposal

[Robin Sommer]

On Tue, May 24, 2016 at 16:21 +0000, you wrote:

> Yeah, I have ideas, but seems like there might be another day of some
> discussion before I try to formally reframe a design doc. Here’s the
> direction I'm thinking:

I like the process you sketch, that sounds like the right way to go to
me.

A few notes, also trying to address some of Adam's comments:

> - the initial submission process involves doing a pull request on the
> bro/cban repo where the only change made is the addition of a
> submodule.  These merges probably can be automated, but if a human
> were to do it, I’d expect it wouldn’t be a time-consuming task

Yeah, maybe that initial merge is one task we leave to a human, who
could then actually take a quick 30sec look at the module to see if
it's not totally off the mark. That would address Adam's point about
what if somebody submits something that's not even a Bro thing (but I
wouldn't go further; e.g., don't try to compile, etc.. Everything
looking roughly right gets in at this time.)

> - submodules that are found to have never been in a working state are
> auto-removed (or could initially be a task that’s not a big deal for a
> human to do every so often if metrics of brokenness are consistently
> available)

Auto-removal sounds dangerous to me; there may be different reasons
why something's not in a good state. I'd leave cleanup to humans too:
if there's a module that's consistently flagged as broken, that's when
we can send a mail to the author and remove it manually if no
improvement is in sight. I'd rather err on the side of having a broken
module than remove something that could actually still be useful.

> - metadata logically can be categorized in two types, one type is
> related to discoverability (tags, author, license, etc) and one type
> is related to interoperability (version number, dependencies)

I wouldn't object to making some meta-data mandatory, per Adam's
comments. For example enforcing having an author and a license would
be useful I think. Author gets us contact information and license is
always worth clarifying.

> - discoverability metadata is aggregated during the nightly quality
> check processes and automatically commits that information to the
> “bro/cban” repo.

Would it be better to maintain this information outside of git in a
state file that clients download? Otherwise the repository will
clutter up quite a bit over time with tons of automatic commits.


Overall, I agree that we can always add more restrictions later if it
turns out necessary. It's not that we'll have 1000s of Bro modules in
there within the first two weeks (as long as we prevent somebody
spamming us).

Robin

-- 
Robin Sommer * ICSI/LBNL * robin at icir.org * www.icir.org/robin