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
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
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
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".
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.
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
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
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 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
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
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
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
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 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
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) &
15 matches
Mail list logo
