I like (2) for cleanliness.
I think some people would be fine with one large package, but in other
cases, you may want the ability to easily enable/disable various standard
scripts. Probably not wanting to maintain the same script in
multiple places, I think that eliminates (3). Towards, (4) &
On Mon, Aug 24, 2020 at 11:26 -0500, Michael Dopheide wrote:
> I like (2) for cleanliness.
Vote counted!
> there should be an easy way to distinguish them from other packages
> when doing a 'zkg list'.
Good point.
Also, one additional thought: Jon reminded me that zkg can manage
dependencie
Hi,
just a few thoughts about this. Generally - I like the idea of breaking this up.
I would like to list a few thoughts about additional technical points that
we should perhaps think about and that play into this decision.
* Testing:
Currently, some of the policy scripts have tests that use
On 8/24/20 9:51 AM, Robin Sommer wrote:
Also, one additional thought: Jon reminded me that zkg can manage
dependencies already. So the "collection" I mentioned could be a
meta-package that depends on all the ones we want.
Yeah, agreed -- I prefer #2 for the same reason.
Best,
Christian
___
On 8/24/20 11:49 AM, Johanna Amann via zeek-dev wrote:
* Testing:
Currently, some of the policy scripts have tests that use Zeek
functionality in rather unique ways / or are the only tests for some
Zeek functionality. The SSL validation scripts are one example.
This, from my point o
On Mon, Aug 24, 2020 at 6:43 AM Robin Sommer wrote:
> 1. Move each into a a separate repository on the zeek/ GitHub
>account.
>
> 2. Similar, but to avoid cluttering zeek/, create a new GitHub
>organization "zeek-packages".
I'm thinking (2). Technically, either one can l
On Mon, Aug 24, 2020 at 11:49 -0700, Johanna Amann wrote:
> This, from my point of view, it would be neat to have a way to still
> easily install a rather large set of packages (potentially nearly
> everything that is in policy at the moment) and run test on them.
While I agree that inte
On Mon, Aug 24, 2020 at 14:15 -0700, Jon Siwek wrote:
> * What's the LTS policy for packages?
Good question. I think would tie it to the Zeek LTS policy, with a
"blessed" version of the meta-package that we recommend (and maintain)
for each currently maintained Zeek version.
Robin
--
Robin
On 25/08/2020 09:46, Robin Sommer wrote:
Agree, and I'd extend that to packages in general, you be a job for an
extended packages.zeek.org to provide autogen'ed documentation.
I like that idea! It would be great to have a standard process for
generating docs for each package.
On 24/08/2020 2
On Tue, Aug 25, 2020 at 3:27 AM Jan Grashöfer
wrote:
>
> I like that idea! It would be great to have a standard process for
> generating docs for each package.
>
I've been working[1] on a template for Zeek packages that consist only of
scripts. It's based heavily on the plugin-support[2] in zeek
On 8/25/20 1:27 AM, Jan Grashöfer wrote:
I think the underlying issue extends to the pcaps as well. If I am not
mistaken, a significant number of test cases make use of the same pcaps.
Having multiple copies of them scattered across different repositories
doesn't feel right.
Good point, yeah. I
To summarize this a bit, below is what I think what I heard so far.
Feel free to respond further, I'll move this over into the ticket
later once we have consensus.
Robin
- General preference to keep packages in individual repositories
hosted inside a new GitHub organization "zeek-packages".
-
Great summary, thanks Robin.
On 8/31/20 2:14 AM, Robin Sommer wrote:
- zkg:
- Could we add a way to "prime" zkg's package cache so that a Zeek
distribution could distribute a snapshot of "zeek-packages" for
direct use; but zkg would still pull in updates if online acces
On Mon, Aug 31, 2020 at 2:14 AM Robin Sommer wrote:
> - zkg:
> - Distinguish standard/recommended packages from others.
Not sure what's meant there, but names/listings would all use
`zeek/zeek-packages/` as a prefix and be a way of distinguishing.
If it's more about organizing meta-packages
On Mon, Aug 31, 2020 at 10:57 -0700, Christian Kreibich wrote:
> ... if we strengthen the notion of packages from the core distribution, we
> may want to ensure zkg can be available from the outset
Yeah, I'd be in favor of tying zkg more closely to Zeek itself so that
it's always available as
15 matches
Mail list logo