[Bro-Dev] bro-pkg v0.3

[Siwek, Jon]

> On Aug 15, 2016, at 10:20 AM, Robin Sommer <robin at icir.org> wrote:
> 
> One suggestion for "Create a Package": I believe the text
> doesn't really say anywhere yet explicitly that a plugin can contain
> these three different things. Maybe add paragraph summarizing what
> "package" actually means at the beginning?

Done.

>> * A package submission process is found in the README of https://github.com/bro/packages
> 
> That sounds all good to me. One nit: In (2): the "this" before
> repository is ambiguous because (1) talks about a different one.

Changed.

> Looks like this the location where we can also require a couple more
> pieces of meta data. I still vote for keeping this minimal, but I
> suggest we require at least an email contact and a license statement
> before accepting a pull request.

Yeah, makes sense to put those bits in the index data, if you decide to require them.

> I'm torn on requiring a version
> number as well: I would like too, but we can't enforce that people
> update it as they make changes; and it would just be useless if people
> don't. So probably better to skip.

I agree.  We depend on git being the authority for versioning anyway, so requiring people to update a metadata file in addition to creating a git tag still borders on useless even as an enforced rule.

> Once this is finalized, do you plan to add a pointer back here from
> the BPM docs?

There was one in the main README/landing-page.  I added another link in the “Registering to a Package Source” walkthrough.  Let me know if there was another place you were expecting to see it, but didn’t.

>> E.g. if there were `bro —config site_dir` and `bro —config plugin_dir`
> 
> Good thought, though why not keep it out of Bro: we can add a script
> "bro-config" to Bro that cmake populates with the right data. That
> would actually be helpful for other stuff as well. That's something we
> could still add for 2.5, too.

Good idea.  I’ll get a branch for that today/tomorrow.

- Jon