On Aug 5, 2014, at 4:41 PM, Robin Sommer <ro...@icir.org> wrote:
> On Mon, Aug 04, 2014 at 22:03 +0000, you wrote:
>
>> Yeah, seems like a reasonable first-step. I’m wondering if it makes
>> sense to break them up even further in to separate repos like
>> "dataseries-bro-plugin" and "elasticsearch-bro-plugin” ?
>
> Yeah, I'm torn on this. It does make sense for the reasons you give,
> but one repository also has its appeal:
>
> - it's easy to just get them all by cloning, or packaging, the one
> thing.
>
> - administratively, we just need to manage/mirror one repo.
>
> - we can add some infrastructure to the repo to easily build and
> test them all at once, including as part of Jenkins.
>
> - we can market that one repo as a vetted source for plugins,
> including plugins maintained externally that follow certain
> standards, like having a maintainer who fixes problems and makes
> sure it works with the current release (we'd ping that person
> when something breaks and remove the plugin if there's no fix).
> [1]
>
> - independent of what we do, people can of course still have their
> own repos elsewhere anyways.
>
> Opinions?
Maybe still have one repo that relies on git submodules, one per plugin?
- Easy to clone everything w/ —recursive.
- Could hold common packaging and testing infrastructure.
- Still has administrative overhead of having to create/mirror many
repos.
Was there more concern regarding admin overhead other than the initial cost of
setting-up/mirroring? Is there a limit to how many repos can be mirrored?
Could also do a hybrid approach where only external plugins are submodules, but
internally maintained ones just get committed directly to main "bro-plugin”
repo. That would cut down on the admin overhead.
Another worry: should the way plugins are organized make it easy to be
selective about which plugins to build/install ? Say that I just want the
dataseries plugin, but also happen satisfy dependencies of the elasticsearch
plugin, would it be more “awkward" for me if all plugins live in same repo and
share build infrastructure? “Awkward” meaning it’s going to
download/build/install things I don’t want.
- Jon
_______________________________________________
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
