[Bro-Dev] CBAN design proposal
vallentin at icir.org
Thu May 26 14:07:16 PDT 2016
> - having both "upgrade" vs "update" commands sounds confusing, I'm
> sure I would constantly mix up the two. Suggest to rename one of
I think this comes from Homebrew (and maybe other package managers as
well). I kinda got used to it in this context, but occasionally still
trip over it. So yeah, I also think we should use either "update" or
"upgrade," but not both.
> - What's the policy for namespaces (both script-land and plugin-land),
> and what's the relationship to the CBAN path? Should people use
> their GitHub name as namespace for their module? On the one hand
> that would be an easy way to avoid conflicts. On the other hand that
> makes forking difficult.
Is it necessary to enforce this? Intuitively, I would just leave
namespacing to the user. Clearly, to be interoperable, a convention
could be using your github handle, but I don't see it being a necessity.
If multiple devs want to collaborate and enhance the same namespace, we
should not make this a cumbersome due to namespace hassles.
> - Originally I wanted to suggest allowing more than one plugin per git
> repository but I really like the idea to leverage submodules, so I'm
> skipping that suggestion. :-)
How do submodules scale? Or asked differently, what are the number
(order of magnitude) of submodules we're expecting?
> - Using a gist for meta data sounds good. We should then also have a
> nice permanent *.bro.org URL redirecting there so that we hide the
> actual location a bit for easier relocation.
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
> - Any thoughts on distributing precompiled plugins? It would be nice
> if, say, I could just install the Mac version of plugin XYZ without
> having to compile it locally. The authors could optionally offer
> selected prebuilds for whatever platforms they want to support.
> Probably more a a feature for CBAN v2, but would be wort keeping
> mind how binaries would fit in.
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.
> - Terminology 1: agree that we should find a better name for CBAN.
Here are some bro'ish suggestions (not all are serious ones):
- brow (part of the logo already)
- broom (sweep new code into bro)
- broil (Bake your enhancements into bro)
- broad (extends Bro in a broader sense)
- broem (pleasing in a literary manner)
- bropane (hot stuff for your bro)
- brorito (original scripts from Mexico!)
- brotein (makes you grow like a bro)
- hebro (how about catering to Isreal?)
- bronx (or to NYC?)
And some random word forging:
- bkg (instead of FreeBSD's pkg)
- lion (animal I like)
- crank (crank up that Bro)
- scrit (tweak on "script")
- berk (a Bro perk...or short for Berkeley)
- bip (pip for Bro)
- bang (starts with a "b" and sounds hip)
- beco (Bro ecosystem)
> The best alternative names I can come up with are "module" or
> "package", which are also overloaded already, but at least more
Of the two, I prefer "module" because "package" to me reminds me of a
compiled thing, which is not always the case. Other than that,
"extension" comes to mind, or maybe "bundle."
> - We could create a public mailing list for CBAN for all discussions
> of individual plugins/modules, including in particular for decisions
> to remove something. Would be good to keep this all open and
...and a Gitter channel, once we have converged on a name :-).
More information about the bro-dev