> On May 26, 2016, at 11:14 PM, Robin Sommer wrote:
>
>> 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
> On May 26, 2016, at 4:07 PM, Matthias Vallentin 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 t
On Thu, May 26, 2016 at 17:41 +, 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
On Thu, May 26, 2016 at 15:57 +, you wrote:
> But we are wrapping everything in the Bro plugin architecture, right?
I think we'll need to play with that a bit still to see how exactly a
minimal script module would be distributed. The binary plugins require
a bit more structure, and are load
On Thu, May 26, 2016 at 14:07 -0700, you wrote:
> Is it necessary to enforce this? Intuitively, I would just leave
> namespacing to the user.
No need to enforce, but it would be good to have some guidelines at
least. And part of the guidelines should be keeping the "Bro"
namespace reserved.
>
Or just bro-ports
On May 26, 2016, at 4:52 PM, Jan Grashöfer wrote:
>> 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 sen
> 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
> - having both "upgrade" vs "update" commands sounds confusing, I'm
> sure I would constantly mix up the two. Suggest to rename one of
> them.
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
> On May 26, 2016, at 10:46 AM, Robin Sommer wrote:
>
> - Let's keep BroControl integration in mind at leat. I agree that a
> standalone client makes most sense right now, but if there's
> something we can do that will make it easier for BroControl later to
> integrate, that's worth preparing
CBAN is a good name. It’s short, easy to say, and what the acronym means, the
“Comprehensive Bro Archive Network”, makes sense. But I don’t really have a
dog in this fight.
--
Jeannette Dopheide
Training and Outreach Coordinator
National Center for Supercomputing Applications
University of
> On May 26, 2016, at 10:46 AM, Robin Sommer wrote:
>
> - Terminology 1: agree that we should find a better name for CBAN.
BroForge?
>
> - Terminology 2: Using "plugin" as the entity name for everything is
> confusing I think, as right now I think most people understand it as
> something th
On Wed, May 25, 2016 at 17:59 +, you wrote:
> https://www.bro.org/development/projects/cban3.html
Looks great to me. Unsorted thoughts/notes:
- Let's keep BroControl integration in mind at leat. I agree that a
standalone client makes most sense right now, but if there's
something we ca
Here’s a revised/alternate design based on feedback so far:
https://www.bro.org/development/projects/cban3.html
Note that I put these at unique URLs and didn’t update in place since they’re
different enough that, if someone tried to follow along from the start of the
thread, I didn’t think it w
> On May 25, 2016, at 11:25 AM, Siwek, Jon wrote:
>
>>
>> On May 25, 2016, at 9:49 AM, Slagell, Adam J wrote:
>>
>> So this has become an involved thread. Do we need a call, or do you think
>> you can pull out enough to get started Jon?
>
> Yes I can reorganize all latest ideas into an alte
> On May 25, 2016, at 9:49 AM, Slagell, Adam J wrote:
>
> So this has become an involved thread. Do we need a call, or do you think you
> can pull out enough to get started Jon?
Yes I can reorganize all latest ideas into an alternate design document. Or if
you meant get started working on th
> On May 25, 2016, at 12:12 AM, Robin Sommer wrote:
>
>> - 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 f
> On May 24, 2016, at 4:46 PM, Matthias Vallentin wrote:
>
> More generally, there will presumably some functionality to add
> "remotes" to one's configuration, allowing plugin writers to point to
> experimental code if they wish. Then they can still hack out code and
> mix it with existing CBAN
> On May 24, 2016, at 2:52 PM, Jan Grashöfer wrote:
>
>
> Imagine there was someone who published an awesome script but a new
> version of Bro breaks it. Another one patched the script and sends the
> patch to the original author. What will happen, in case he does not
> respond? Personally I do
> On May 25, 2016, at 12:12 AM, Robin Sommer wrote:
>
> 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
So this has bec
On Tue, May 24, 2016 at 16:21 +, 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
> On May 24, 2016, at 4:46 PM, Matthias Vallentin wrote:
>
> If I understold it correctly, I don't think that the central CBAN
> repository will accumulate clutter. The automatic checks will help
> simply age out repos that do not comply with the minimal standards. It's
> up to the devs to compl
(I will respond to the actual proposal in more depth later.)
> That is a good point. I am more concerned about accumulating clutter.
If I understold it correctly, I don't think that the central CBAN
repository will accumulate clutter. The automatic checks will help
simply age out repos that do no
> - it’s not a big deal for a submodule to temporarily enter in to a broken
> state — cban users can always roll back to a previous version or just
> uninstall it. It’s up to the community to communicate/collaborate directly
> w/ the author here to get things fixed.
I really like the community
> On May 24, 2016, at 12:40 PM, Siwek, Jon wrote:
>
> I lean toward starting w/ the most streamlined and least complicated approach
> and seeing what quality control checks you need to layer on top of it because
> we might just expend a lot of effort planning for problems that don’t actual
>
> On May 24, 2016, at 11:49 AM, Slagell, Adam J wrote:
>
> I propose that we keep mandatory checks minimal, but not non-existent, and
> then we reevaluate when we have real data about how well this works. But I
> would really like more feedback from the community. Maybe I am an outlier
> here
> On May 24, 2016, at 12:07 PM, Siwek, Jon wrote:
>
>>
>> On May 23, 2016, at 6:30 PM, Slagell, Adam J wrote:
>>
>> I guess there is a balance here. If we do no mandatory checks and you could
>> submit something that isn’t even a Bro plugin, the repository could become
>> cluttered with jun
> On May 23, 2016, at 6:30 PM, Slagell, Adam J wrote:
>
> I guess there is a balance here. If we do no mandatory checks and you could
> submit something that isn’t even a Bro plugin, the repository could become
> cluttered with junk. Do we really want things that don’t even “compile”?
The clu
> On May 24, 2016, at 11:21 AM, Siwek, Jon wrote:
>
> I think all those points make things easy on contributors, minimize direct
> involvement of the Bro Team in sorting out problems related to particular
> plugins, and provide a useful way for users to discover and maintain Bro
> plugins. T
> On May 23, 2016, at 4:59 PM, Robin Sommer wrote:
>
>> That would make life easier for authors, and that’s maybe even a
>> higher priority than maximizing the quality/consistency of user
>> experience because, without authors, there won’t be much for users to
>> experience in the first place.
>
> On May 23, 2016, at 5:40 PM, Robin Sommer wrote:
>
>>
>> When a contributor submits a new script, there would be some mandatory
>> checks that would need to pass for the script to be included:
>
> The "mandatory" is where I disagree. I believe there's just to much
> involved with any initial
On Mon, May 23, 2016 at 11:22 -0500, you wrote:
> When a contributor submits a new script, there would be some mandatory
> checks that would need to pass for the script to be included:
The "mandatory" is where I disagree. I believe there's just to much
involved with any initial vetting, even if
On Mon, May 23, 2016 at 17:26 +, you wrote:
> To clarify, is the concern w/ the amount of non-automatable tasks or
> with the model of requiring authors to “ping” some middle-man in order
> for updates to their plugin to become visible to all CBAN users?
Both actually. Putting us into the pa
> On May 21, 2016, at 5:44 PM, Robin Sommer wrote:
>
> I'm getting concerned that we're creating an unncessary bottleneck by
> imposing the Bro Team into the critical path for submissions and
> updates. Why not let people control their stuff themselves? They'd
> register things with CBAN to make
I think we're generally on the same page, but I wanted to elaborate a bit
on what I envisioned with the plugin submission process.
When a contributor submits a new script, there would be some mandatory
checks that would need to pass for the script to be included:
* Is the plugin structure valid?
On Sat, May 21, 2016 at 23:16 +, you wrote:
> I think there is a broad spectrum from no interaction to vetting and
> pulling into the main repository. It is about finding the right
> balance.
Yep, and I'm arguing for going very far towards the "no interaction"
side, with just some automatic
> On May 21, 2016, at 5:44 PM, Robin Sommer wrote:
>
> As I read through the design doc, I started questioning our plan of
> curating CBAN content. I know that's what we've been intending to do,
> but is that really the best approach? I don't know of script
> repositories for other languages th
> In other words, my proposal is to put authors into control of their
> code, and make them fully responsible for it too --- not us. We'd just
> connect authors with users, with as little friction as possible.
>
I support this completely.
> If we want some kind of quality measure, we could intr
On Fri, May 20, 2016 at 20:16 +, Jon wrote:
> Here’s an updated design doc for CBAN, a plugin manager for Bro, with
> some new ideas on how it could work:
Cool, thanks. I'm going to send some feedback but first I wanted to
bring something up that might be controversial. :-)
As I read throu
Here’s an updated design doc for CBAN, a plugin manager for Bro, with some new
ideas on how it could work:
https://www.bro.org/development/projects/cban2.html
Eventually it may be good to ask for feedback on bro-users to make sure we’re
not missing important features the community would want, b
39 matches
Mail list logo
