[Bro-Dev] CBAN design proposal
jsiwek at illinois.edu
Fri May 27 08:58:44 PDT 2016
> On May 26, 2016, at 4:07 PM, Matthias Vallentin <vallentin at icir.org> wrote:
> How do submodules scale? Or asked differently, what are the number
> (order of magnitude) of submodules we're expecting?
I imagine it will scale because when a user clones the main/parent CBAN repo, we’re telling them to just clone that and *not* recursively clone all the submodules (unlike the process for the ‘bro’ repo that you’re familiar with). Then the user will pick and choose the individual submodules they want. I don’t know much the average user will end up installing, but I’m guessing in the order of 10s and not 100s.
Does that make sense or is there something more to your concern I might be missing or misunderstood?
> Is the idea that all meta data will reside in a single file? What format
> would that file be, YAML? If each user repo has 20 lines of meta data,
> then the file would be 2KB to track 100 repositories. Seems fine to me,
> but I wonder how much will end up in there to get a tractable upper
I didn’t have a standardized format in mind to begin with, I just planned to do “the simplest thing that works” first and then let it evolve from there (clients can be updated in a way that’s resilient to changes in the format), but if enough people want to start w/ a particular format to begin with that’s fine too.
> Binaries are a big project, I believe. Not only do we need to support
> differently platforms, but also different OS versions and distributions.
> It would probably mean we have to invest into a bigger Jenkins setup,
> and then push the binaries into a CDN after a successful build.
I imagined it would still be left up to individual authors to make precompiled binaries available and support/maintain them. It would also be optional for them to make binaries available, not required.
More information about the bro-dev