[Bro-Dev] CBAN design proposal

[Robin Sommer]

On Thu, May 26, 2016 at 17:41 +0000, you wrote:

> I imagined it being part of the nightly process that does quality/metric gathering.

Yeah, makes sense.

> Is it an important use case for the client to be able to interact w/
> other repos that are structured like the one the Bro Team will be
> hosting?  Seems less likely that people will want to do that
> especially if the CBAN repository is easy enough for people to submit

Yeah, agree it's less important with that liberal model. I would still
like to support it though unless it's a major pain.

> But maybe there’s a slicker thing you could add to the Bro language
> itself to let users specify a custom namespace mapping for certain
> file paths allowing them to resolve conflicts themselves.

Conflict reporting sounds good, renaming could get confusing.

> The client's “update” command will do a “git pull” in the parent repo
> and then a “git fetch” in any installed submodules.

So does that mean the client ignores the version that the central CBAN
parent repository points to? Say Seth finished version 1.0 of his
cool-plugin and files a merge request. We add the submodule to CBAN;
it will point to 1.0. Then Seth updates to 1.1 on his end. CBAN would
still point to 1.0, but clients would just move their local clones to
1.1, ignoring the parent repository's state. Is that what you have in
mind?

Robin

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